A method and system for modeling upstream and downstream relationships of water systems based on domain-specific language and automatically mapping to graph database

Abstract

The application relates to a method for modeling upstream and downstream relationships of water systems based on a domain-specific language and automatic mapping of a graph database, which comprises the following steps: converting nodes of a water system network into DSL text according to a pre-designed domain-specific language; automatically completing the DSL text; automatically checking the automatically completed DSL text; performing relationship analysis and data structuring on the automatically checked DSL text, thereby producing node and relationship data tables; importing the node and relationship data tables into a graph database; and visualizing the data in the graph database. The application can abstract and check the syntax level according to the structural relationship characteristics of water systems, thereby achieving high self-adaptation at the business level, and greatly improving the modeling efficiency, accuracy and automation level.

Description

Technical Field

[0001] This application relates to the field of water environment management and information system integration, and in particular to a method and system for modeling upstream and downstream relationships in water systems and automatically mapping graph databases based on a domain-specific language. Background Technology

[0002] Currently, the upstream and downstream relationships of monitoring points at river cross-sections and river nodes are mostly modeled manually using tables, general databases, or through SQL (Structured Query Language) statements and programming scripts. This data is generally imported into the database manually or semi-automatically to support watershed analysis, source tracing, and visualization applications.

[0003] In practical applications, relevant management and technical personnel typically compile the relationship data between monitoring sections and watershed nodes into spreadsheets such as Excel, or directly input them into a pre-defined table structure in a database. Subsequently, developers write scripts based on this spreadsheet data to achieve data migration, relationship modeling, and network structure visualization. While these methods can meet the needs of water system relationship management on a certain scale, they often require extensive manual adjustments and repeated verification when facing complex network structures, diverse node types, and scenarios involving multiple tributaries and multi-level confluences.

[0004] Furthermore, existing technologies largely rely on general-purpose data modeling tools and custom scripts, making it difficult to provide specially optimized description languages ​​and automated verification mechanisms for modeling special network relationships such as water systems. This results in significant deficiencies in model scalability, automation, and ease of use in practical engineering, limiting their effectiveness in large-scale, dynamically changing environments.

[0005] Currently, traditional methods mainly suffer from the following drawbacks:

[0006] Inefficient modeling: Relational tables and scripts are difficult to adapt to rapidly changing network structures and the maintenance of large-scale nodes and relationships;

[0007] Human error is common: Table, SQL or script operations require manual adjustment and mapping, which can easily lead to problems such as missing nodes, duplicate relationships or incorrect connections.

[0008] Not suitable for multi-type, multi-role nodes: It is difficult to describe and handle real-world business scenarios such as multiple branch inflow points and dynamic changes in node types.

[0009] Insufficient verification: The lack of automatic verification mechanisms for data uniqueness, node roles, and upstream and downstream legitimacy leads to high costs for subsequent data cleaning.

[0010] In summary, the reason why traditional methods have shortcomings is that neither traditional data tables nor general scripts perform syntactic-level abstraction and validation of the characteristics of water system structure relationships, and therefore cannot achieve a high degree of adaptability at the business layer. Therefore, how to perform syntactic-level abstraction and validation of the characteristics of water system structure relationships to achieve a high degree of adaptability at the business layer is a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0011] The purpose of this application is to overcome the shortcomings in the above-mentioned background technology and propose a method and system for modeling upstream and downstream relationships in water systems and automatically mapping graph databases based on a domain-specific language (DSL). This method enables the rapid definition of cross-section nodes and multi-level upstream and downstream relationships using intuitive text language, and automatically completes data uniqueness verification, node type identification, inflow point identification, and full-process data entry into the database, greatly improving modeling efficiency, accuracy, and automation level.

[0012] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0013] A method for modeling upstream and downstream relationships in a water system and automatically mapping data to a graph database based on a domain-specific language includes the following steps: Step S1, converting the nodes of the water system network into DSL text according to a pre-designed domain-specific language; Step S2, automatically completing the DSL text; Step S3, automatically validating the automatically completed DSL text; Step S4, parsing and structuring the automatically validated DSL text to generate node and relation data tables; Step S5, importing the node and relation data tables into a graph database; Step S6, visualizing the data in the graph database.

[0014] The method for modeling upstream and downstream relationships in a water system and automatically mapping a graph database based on a domain-specific language (DSL) as described above preferably includes the following sub-steps in step S1: Step S11: Define the mapping of nodes in the water system network and assign unique node IDs to each node; Step S12: Describe the upstream and downstream relationships of each node in the water system network by applying the node IDs of each node using the pre-designed syntax rules of the domain-specific language (DSL); Step S13: Verify the statements describing the upstream and downstream relationships of each node in the water system network according to predetermined syntax verification rules to obtain the DSL text.

[0015] The method for modeling upstream and downstream relationships in a water system and automatically mapping graph databases based on a domain-specific language, as described above, preferably assigns a unique node ID to each node in the water system network using a mapping dictionary and specifies the cross-sectional name of each node in the water system network.

[0016] The method for modeling upstream and downstream relationships in water systems and automatically mapping graph databases based on domain-specific languages, as described above, preferably assigns unique node IDs to nodes in the water system network and also specifies auxiliary information for each node in the water system network.

[0017] The method for modeling upstream and downstream relationships in water systems and automatically mapping graph databases based on domain-specific languages, as described above, preferably describes the upstream and downstream relationships of each node in the water system network. The description syntax rule uses a combination of "node type + node ID" and the flow direction identifier "->" to express the flow direction of the water system.

[0018] A system for modeling upstream and downstream relationships in a water system and automatically mapping a graph database based on a domain-specific language includes: a DSL text conversion module, an auto-completion module, an auto-validation module, a parsing and data structuring module, an import module, and a visualization module. The DSL text conversion module converts nodes of the water system network into DSL text based on a pre-designed domain-specific language. The auto-completion module automatically completes the DSL text. The auto-validation module automatically validates the automatically completed DSL text. The parsing and data structuring module performs relation parsing and data structuring on the automatically validated DSL text, thereby generating node and relation data tables. The import module imports the node and relation data tables into a graph database. The visualization module visualizes the data in the graph database.

[0019] The above-described domain-specific language (DSL)-based water system upstream-downstream relationship modeling and graph database automatic mapping system preferably includes a DSL text conversion module comprising: a node ID allocation submodule, a relationship description submodule, and a statement verification submodule. The node ID allocation submodule defines the mapping of nodes in the water system network, assigning unique node IDs to each node. The relationship description submodule, using pre-designed DSL syntax rules, applies the node ID of each node in the water system network to describe the upstream-downstream relationships of each node. The statement verification submodule verifies the statements describing the upstream-downstream relationships of each node in the water system network according to predetermined syntax verification rules, thereby obtaining the DSL text.

[0020] In the above-described domain-specific language-based water system upstream and downstream relationship modeling and graph database automatic mapping system, preferably, the node ID allocation submodule assigns a unique node ID to each node of the water system network through a mapping dictionary and specifies the cross-section name of each node of the water system network.

[0021] In the above-described domain-specific language-based water system upstream and downstream relationship modeling and graph database automatic mapping system, preferably, the node ID allocation submodule assigns a unique node ID to the nodes of the water system network and also specifies auxiliary information for each node of the water system network.

[0022] As described above, in the water system upstream and downstream relationship modeling and graph database automatic mapping system based on domain-specific language, preferably, the relationship description submodule describes the upstream and downstream relationships of each node in the water system network. The description syntax rule adopts a combination of "node type + node ID" and flow direction relationship identifier "->" to express the water system flow direction.

[0023] Compared to the aforementioned background technologies, this application can significantly improve modeling efficiency, automatically generating and storing dozens or hundreds of nodes and complex multi-level relationships in minutes; improve accuracy, eliminating traditional manual errors such as duplication, omission, and misconnection; automatically verify data, capturing inconsistent or unreasonable data in advance, reducing manual cleaning and rework costs; be easily expandable and maintainable, making it extremely convenient to add new node types or expand to other fields (such as pipeline networks and ecological networks); and have strong compatibility, seamlessly connecting with existing data tables and watershed management platforms, and being compatible with various graph databases. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0025] Figure 1 This is a flowchart of a method for modeling upstream and downstream relationships in a water system and automatically mapping graph databases based on a domain-specific language, provided in an embodiment of this application.

[0026] Figure 2 This is a flowchart provided in an embodiment of the present application for converting DSL text for nodes in a water network according to pre-designed syntax rules of a domain-specific language (DSL);

[0027] Figure 3 This is a schematic diagram of the syntax rules of a domain-specific language (DSL) provided in an embodiment of this application;

[0028] Figure 4 This is a schematic diagram of a water system upstream and downstream relationship modeling and graph database automatic mapping system based on a domain-specific language, provided in an embodiment of this application. Detailed Implementation

[0029] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. Additionally, spatial relation terms such as "upper," "lower," "front," "rear," "left," and "right" are used for ease of description to explain the positional relationship between two components. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0030] Example 1

[0031] like Figure 1 As shown, this application provides a method for modeling upstream and downstream relationships in water systems and automatically mapping graph databases based on a domain-specific language, including the following steps:

[0032] Step S1: Convert the nodes of the water network into DSL text according to the pre-designed domain-specific language;

[0033] Among them, the pre-designed domain-specific language is a structured text that expresses the nodes of the water system network and their upstream and downstream relationships, and is stored in the corresponding computer system. Structured text is a text form with a clear format and organization rules. Domain-Specific Language (DSL) is a special language designed for a specific domain. Compared with general-purpose languages ​​(such as Java and Python), it focuses more on solving problems in a specific domain and has the characteristics of being concise, efficient, and easy to read.

[0034] When performing text conversion on nodes of a water network, the nodes are input into the corresponding computer system. The computer system then converts the nodes into DSL text according to the pre-designed syntax rules of a domain-specific language (DSL). Specifically, for example... Figure 2 As shown, this application converts the DSL text of nodes in a water system network according to the pre-designed syntax rules of a domain-specific language (DSL), and includes the following steps:

[0035] Step S11: Define the mapping of nodes in the water system network to assign a unique node ID to each node in the water system network.

[0036] like Figure 3 As shown, firstly, the corresponding computer system assigns a unique node ID to each node in the water system network using a mapping dictionary, and specifies the cross-section name for each node. The mapping dictionary is a collection of key-value pairs. Optionally, the computer can also specify auxiliary information such as cross-section code and province of origin for each node in the water system network.

[0037] For example: mapping = {

[0038] 1:{"Section Name":"Cuijiahe Bottom"},

[0039] 2:{"Section Name":"Zhaikou"},

[0040] 3:{"Section Name":"Sanchakou","Province":"Guizhou"},

[0041] ...}

[0042] The node ID (e.g., 1, 2, 3, ...) is referenced in subsequent statements describing the upstream and downstream relationships of each node in the water system network using the domain-specific language DSL.

[0043] Step S12: Using the pre-designed syntax rules of the domain-specific language DSL, describe the upstream and downstream relationships of each node in the water system network by applying the node ID of each node in the water system network.

[0044] like Figure 3 As shown, the corresponding computer system describes the upstream and downstream relationships of each node in the water system network. The description syntax rule uses a combination of "node type + node ID" and the flow direction identifier "->" to express the flow direction of the water system.

[0045] For example, the statement describing the upstream and downstream relationships of each node in a water system network is as follows:

[0046] start 1->mid_2

[0047] mid 2->mid_2

[0048] mid_2->end 3

[0049] Node types and syntax rules:

[0050] start:

[0051] Syntax: start node ID

[0052] Note: This represents the starting node of a water system network (e.g., the upstream source node), and it cannot have an upstream node.

[0053] mid:

[0054] Syntax: mid node ID

[0055] Explanation: This indicates an intermediate node in a water system network. It has both upstream and downstream nodes and can serve as a regular monitoring point or a tributary confluence point.

[0056] end:

[0057] Syntax: end node ID

[0058] Note: This indicates the terminal node of the water system network (e.g., exit point, lake mouth, etc.), which cannot have downstream nodes.

[0059] Ingress point (e.g., _5):

[0060] Syntax: mid_N (or start_N, end_N, depending on the actual semantic definition)

[0061] Note: The inflow point is represented by "underscore + node ID". The inflow point is essentially the confluence of multiple upstream nodes. _N indicates an inflow point whose primary identifier is the water network node numbered N.

[0062] Flow direction relationship:

[0063] The flow relationship is represented by the flow relationship symbol "->". The left side of the flow relationship symbol is the upstream node, and the right side of the flow relationship symbol is the downstream node.

[0064] Step S13: Verify the statements describing the upstream and downstream relationships of each node in the water system network according to the predetermined syntax verification rules, thereby obtaining the DSL text;

[0065] After the statement describing the upstream and downstream relationships of each node in the water system network is obtained, the corresponding computer system verifies the statement describing the upstream and downstream relationships of each node in the water system network according to the predetermined syntax verification rules. If the verification is successful, the nodes of the water system network are converted into DSL text; otherwise, the nodes of the water system network are re-converted into text.

[0066] The syntax validation rules specifically include the following:

[0067] Node full coverage rule: All node IDs appearing in statements describing the upstream and downstream relationships of nodes in a water system network must exist in the definition of the mapping dictionary.

[0068] start node constraint: the start node cannot be the node to the right of any statement (i.e., it cannot be the downstream node of other nodes).

[0069] end node constraint: the end node cannot be the left-hand node of any statement (i.e., it cannot be the upstream node of other nodes).

[0070] mid node constraint: A mid node must have at least one upstream node and one downstream node.

[0071] Node type uniqueness: Each node ID can only be declared as one node type within a domain-specific language DSL (e.g., it cannot be both a mid node and an end node).

[0072] Inbound point (_N) constraint:

[0073] The inflow point (e.g., _2) must appear as a downstream node at least twice (i.e., at least two upstream nodes flow into the inflow point) to ensure it is a valid multi-branch inflow scenario. In addition, the inflow point must have a corresponding node ID (e.g., 2) mapped in the mapping dictionary and marked as a specific type (e.g., CONFLUENCE).

[0074] As an example:

[0075] mapping = {

[0076] 1:{"Section Name":"A"},

[0077] 2:{"Section Name":"B"},

[0078] 3:{"Section Name":"C"}

[0079] }

[0080] #DSL relational statements:

[0081] start 1->mid_2

[0082] mid 2->mid_2

[0083] mid_2->end 3

[0084] Here, start 1 indicates that A is the starting node, mid 2 indicates that B is an intermediate node, mid_2 indicates the inflow point identified by B (e.g., B is the inflow point where multiple branches merge), and end 3 indicates that C is the ending node. Notably, mid_2 is pointed to twice as a downstream node (by nodes with ID 1 and ID 2 respectively), which conforms to the inflow point verification rules.

[0085] Real-world example:

[0086] mapping = {

[0087] 1:{"Section Name":"Xiaheyan, Zhongwei"},

[0088] 2:{"Section Name":"Xiangshan Lake"},

[0089] 3:{"Section Name":"Ershilipu"},

[0090] 4:{"Section Name":"Third Battalion"},

[0091] 5:{"Section Name":"Quanyanshan"},

[0092] 6:{"Section Name":"Jinsha Bay"},

[0093] ...}

[0094] #DSL relational statements:

[0095] start 1->mid 2

[0096] mid 2->mid_5

[0097] start 3->mid 4

[0098] mid 4 -> mid 5

[0099] mid 5->mid_5

[0100] mid_5->mid 6

[0101] mid 6->mid_7

[0102] Step S2: Perform automatic completion on the DSL text;

[0103] After converting the nodes of the water system network into DSL text, for nodes in the DSL text that only provide the cross-section name but lack a unique cross-section code, the corresponding computer system should compare them with the relevant information in the master data table (e.g., the national control cross-section table, which is used to record relevant information of national surface water environmental quality monitoring cross-sections) to automatically complete the cross-section code for nodes that are missing a cross-section code.

[0104] In addition, for nodes with duplicate section names in DSL text, the corresponding computer system automatically completes auxiliary information (e.g., the province of origin) for nodes with duplicate section names to accurately locate the nodes. If the node cannot be uniquely located, an error message is displayed.

[0105] Step S3: Automatically validate the autocompleted DSL text;

[0106] After automatically completing the DSL text, the computer's corresponding system also automatically verifies whether all nodes defined in the DSL text fully cover the mapping dictionary, whether the node roles are unique, whether the upstream and downstream nodes of the start / end nodes meet the corresponding constraints, and whether the upstream nodes of the ingress point meet the corresponding constraints, thereby eliminating logical and data layer errors in the DSL text.

[0107] Step S4: Perform relation parsing and data structuring on the automatically validated DSL text to generate node and relation data tables;

[0108] After automatically validating the DSL text, the corresponding computer system first splits the DSL text into tokens. For example, the DSL text STATION S1{name:"Upstream Station",type:MAIN} is split into: STATION, S1, {, name, :, "Upstream Station",,, type, :, MAIN,}. Then, according to the syntax rules, the tokens are organized into an Abstract Syntax Tree (AST). This can be done using ANTLR or the ply library of Python (ANTLR and Python are two commonly used tools for building the core components of compilers or parsers—lexers and parsers) (the ply library is a lexer and parser generation tool implemented in Python, used to convert text into structured data). Next, the AST is traversed to extract the metadata of nodes and relations, and node and relation data tables are generated based on this metadata, for example, using Pandas. DataFrame (a two-dimensional, tabular data structure, similar to an Excel spreadsheet, SQL table, or two-dimensional table in a database).

[0109] Furthermore, the corresponding computer system must assign type labels (e.g., STATION, CONFLUENCE) to nodes and nodes in the relational data table, so that the corresponding computer system can clearly distinguish the differences between different nodes through type labels. For example: STATION (hydrological station): node attributes include "monitoring equipment ID, monitoring frequency, historical water level data", and its main function is "recording hydrological information"; CONFLUENCE (confluence point): node attributes include "number of tributaries, name of the main channel, confluence angle", and its main function is "calculating the water flow velocity after confluence".

[0110] Step S5: Import the node and relationship data tables into the graph database;

[0111] The corresponding computer system provides an interface for batch writing to graph databases such as Neo4j. Neo4j is an open-source graph database specifically designed for storing, managing, and querying graph-structured data centered around "nodes" and "relationships." The corresponding computer system imports batches of node and relationship data tables into the graph database through the graph database interface using a single command (e.g., LOADCSV), achieving efficient data import of nodes and relationships.

[0112] For each node's upstream and downstream relationships, the corresponding computer system automatically constructs a bidirectional (upstream / downstream) graph edge based on the node and the upstream and downstream relationships in the relationship data table. The graph edge is the structure connecting two nodes and is used to represent the relationship between them. This application supports batch import and concurrent writing, lowering the technical threshold and improving efficiency, allowing non-professionals to quickly migrate data to a graph database without manually writing complex import code or processing data row by row.

[0113] Step S6: Visualize the data in the graph database;

[0114] Users can directly browse and analyze the network relationships of data in graph databases using visualization tools (such as Neo4j Browser), and periodically synchronize, validate, or expand the database using automated tools. These visualization tools intuitively display the data structure through a graphical interface (nodes, edges, attributes), helping users discover patterns, verify logic, or support decision-making. Neo4j Browser, a built-in visualization tool of the Neo4j graph database, can be accessed directly through a browser and allows execution of Cypher queries, graphically displaying nodes and relationships. Cypher is the query language for the Neo4j graph database, specifically designed for attribute graphs, providing an efficient and intuitive query method.

[0115] Example 2

[0116] like Figure 4 As shown, this application provides a water system upstream and downstream relationship modeling and graph database automatic mapping system 400 based on domain-specific language, including: DSL text conversion module 410, completion and uniqueness verification module 420, automatic verification module 430, parsing and data structuring module 440, import module 450 and visualization module 460.

[0117] The DSL text conversion module 410 converts the nodes of the water network into DSL text according to a pre-designed domain-specific language.

[0118] Among them, the pre-designed domain-specific language is a structured text that expresses the nodes of the water system network and their upstream and downstream relationships, and is stored in the corresponding computer system. Structured text is a text form with a clear format and organization rules. Domain-Specific Language (DSL) is a special language designed for a specific domain. Compared with general-purpose languages ​​(such as Java and Python), it focuses more on solving problems in a specific domain and has the characteristics of being concise, efficient, and easy to read.

[0119] When converting the nodes of the water system network into text, the nodes are input into the DSL text conversion module 410. The DSL text conversion module 410 converts the nodes of the water system network into DSL text according to the pre-designed syntax rules of the domain-specific language DSL. Specifically, the DSL text conversion module 410 includes: a node ID allocation submodule 411, a relationship description submodule 412, and a statement validation submodule 413.

[0120] Among them, the node ID allocation submodule 411 maps and defines the nodes of the water system network to assign a unique node ID to each node of the water system network.

[0121] First, the node ID allocation submodule 411 assigns a unique node ID to each node in the water system network using a mapping dictionary, and specifies the cross-section name of each node in the water system network. The mapping dictionary is a collection of key-value pairs. Optionally, the node ID allocation submodule 411 can also specify auxiliary information such as cross-section code and province of origin for each node in the water system network.

[0122] For example: mapping = {

[0123] 1:{"Section Name":"Cuijiahe Bottom"},

[0124] 2:{"Section Name":"Zhaikou"},

[0125] 3:{"Section Name":"Sanchakou","Province":"Guizhou"},

[0126] ...}

[0127] The node ID (e.g., 1, 2, 3, ...) is referenced in subsequent statements describing the upstream and downstream relationships of each node in the water system network using the domain-specific language DSL.

[0128] The relation description submodule 412 describes the upstream and downstream relationships of each node in the water system network by applying the node ID of each node in the water system network using the syntax rules of a pre-designed domain-specific language (DSL).

[0129] The relationship description submodule 412 describes the upstream and downstream relationships of each node in the water system network. The description syntax rule uses a combination of "node type + node ID" and the flow direction relationship identifier "->" to express the flow direction of the water system.

[0130] For example, the statement describing the upstream and downstream relationships of each node in a water system network is as follows:

[0131] start 1->mid_2

[0132] mid 2->mid_2

[0133] mid_2->end 3

[0134] Node types and syntax rules:

[0135] start:

[0136] Syntax: start node ID

[0137] Note: This represents the starting node of a water system network (e.g., the upstream source node), and it cannot have an upstream node.

[0138] mid:

[0139] Syntax: mid node ID

[0140] Explanation: This indicates an intermediate node in a water system network. It has both upstream and downstream nodes and can serve as a regular monitoring point or a tributary confluence point.

[0141] end:

[0142] Syntax: end node ID

[0143] Note: This indicates the terminal node of the water system network (e.g., exit point, lake mouth, etc.), which cannot have downstream nodes.

[0144] Ingress point (e.g., _5):

[0145] Syntax: mid_N (or start_N, end_N, depending on the actual semantic definition)

[0146] Note: The inflow point is represented by "underscore + node ID". The inflow point is essentially the confluence of multiple upstream nodes. _N indicates an inflow point whose primary identifier is the water network node numbered N.

[0147] Flow direction relationship:

[0148] The flow relationship is represented by the flow relationship symbol "->". The left side of the flow relationship symbol is the upstream node, and the right side of the flow relationship symbol is the downstream node.

[0149] The statement verification submodule 413 verifies the statements describing the upstream and downstream relationships of each node in the water system network according to the predetermined syntax verification rules, thereby obtaining the DSL text.

[0150] After describing the upstream and downstream relationships of each node in the water system network, the statement verification submodule 413 verifies the statement describing the upstream and downstream relationships of each node in the water system network according to the predetermined syntax verification rules. If the verification is successful, the nodes of the water system network are converted into DSL text; otherwise, the nodes of the water system network are re-converted into text.

[0151] The syntax validation rules specifically include the following:

[0152] Node full coverage rule: All node IDs appearing in statements describing the upstream and downstream relationships of nodes in a water system network must exist in the definition of the mapping dictionary.

[0153] start node constraint: the start node cannot be the node to the right of any statement (i.e., it cannot be the downstream node of other nodes).

[0154] end node constraint: the end node cannot be the left-hand node of any statement (i.e., it cannot be the upstream node of other nodes).

[0155] mid node constraint: A mid node must have at least one upstream node and one downstream node.

[0156] Node type uniqueness: Each node ID can only be declared as one node type within a domain-specific language DSL (e.g., it cannot be both a mid node and an end node).

[0157] Inbound point (_N) constraint:

[0158] The inflow point (e.g., _2) must appear as a downstream node at least twice (i.e., at least two upstream nodes flow into the inflow point) to ensure it is a valid multi-branch inflow scenario. In addition, the inflow point must have a corresponding node ID (e.g., 2) mapped in the mapping dictionary and marked as a specific type (e.g., CONFLUENCE).

[0159] As an example:

[0160] mapping = {

[0161] 1:{"Section Name":"A"},

[0162] 2:{"Section Name":"B"},

[0163] 3:{"Section Name":"C"}

[0164] }

[0165] #DSL relational statements:

[0166] start 1->mid_2

[0167] mid 2->mid_2

[0168] mid_2->end 3

[0169] Here, start 1 indicates that A is the starting node, mid 2 indicates that B is an intermediate node, mid_2 indicates the inflow point identified by B (e.g., B is the inflow point where multiple branches merge), and end 3 indicates that C is the ending node. Notably, mid_2 is pointed to twice as a downstream node (by nodes with ID 1 and ID 2 respectively), which conforms to the inflow point verification rules.

[0170] Real-world example:

[0171] mapping = {

[0172] 1:{"Section Name":"Xiaheyan, Zhongwei"},

[0173] 2:{"Section Name":"Xiangshan Lake"},

[0174] 3:{"Section Name":"Ershilipu"},

[0175] 4:{"Section Name":"Third Battalion"},

[0176] 5:{"Section Name":"Quanyanshan"},

[0177] 6:{"Section Name":"Jinsha Bay"},

[0178] ...}

[0179] #DSL relational statements:

[0180] start 1->mid 2

[0181] mid 2->mid_5

[0182] start 3->mid 4

[0183] mid 4 -> mid 5

[0184] mid 5->mid_5

[0185] mid_5->mid 6

[0186] mid 6->mid_7

[0187] The auto-completion module 420 performs auto-completion on DSL text.

[0188] After converting the nodes of the water system network into DSL text, for nodes in the DSL text that only provide the cross-section name but lack a unique cross-section code, the auto-completion module 420 compares them with the relevant information in the master data table (e.g., the national control cross-section table, a table used to record relevant information of national surface water environmental quality monitoring cross-sections), thereby automatically completing the cross-section code for nodes that are missing a cross-section code.

[0189] In addition, for nodes with duplicate section names in the DSL text, the auto-completion module 420 automatically completes auxiliary information (e.g., the province) for the nodes with duplicate section names to accurately locate the nodes with duplicate section names. If the node cannot be uniquely located, an error message will be displayed.

[0190] The automatic verification module 430 automatically verifies the DSL text after auto-completion.

[0191] After automatically completing the DSL text, the automatic verification module 430 also automatically verifies whether all nodes defined in the DSL text fully cover the mapping dictionary, whether the node roles are unique, whether the upstream and downstream nodes of the start / end nodes meet the corresponding constraints, and whether the upstream nodes of the ingress point meet the corresponding constraints, thereby eliminating logical and data layer errors in the DSL text.

[0192] The parsing and data structuring module 440 performs relation parsing and data structuring on the automatically validated DSL text, thereby generating node and relational data tables.

[0193] After automatically validating the DSL text, the parsing and data structuring module 440 first splits the DSL text into tokens. For example, the DSL text STATION S1{name:"Upstream Station",type:MAIN} is split into: STATION, S1, {, name, :, "Upstream Station",,, type, :, MAIN,}. Then, the tokens are organized into an Abstract Syntax Tree (AST) according to grammar rules. This can be achieved using ANTLR or the ply library (a Python tool for generating lexers and parsers to convert text into structured data), which can be used to generate the AST from the tokens. Next, the AST is traversed to extract metadata about nodes and relationships. Based on this metadata, node and relationship data tables are generated, for example, using Pandas. DataFrame (a two-dimensional, tabular data structure, similar to an Excel spreadsheet, SQL table, or two-dimensional table in a database).

[0194] Furthermore, the parsing and data structuring module 440 must also specify type labels (e.g., STATION, CONFLUENCE) for nodes and nodes in the relational data table, so that the parsing and data structuring module 440 can clearly distinguish the differences between different nodes through type labels. For example: STATION (hydrological station): node attributes include "monitoring equipment ID, monitoring frequency, historical water level data", and its main function is "recording hydrological information"; CONFLUENCE (confluence point): node attributes include "number of tributaries, name of the main channel, confluence angle", and its main function is "calculating the water flow velocity after confluence".

[0195] Import module 450 imports node and relation data tables into the graph database.

[0196] The import module 450 provides an interface for batch writing to graph databases such as Neo4j. Neo4j is an open-source graph database specifically designed for storing, managing, and querying graph-structured data centered around "nodes" and "relationships." The import module 450 imports batches of node and relationship data tables into the graph database using a single command (e.g., LOAD CSV), achieving efficient data import of nodes and relationships.

[0197] For each node's upstream and downstream relationships, the import module 450 automatically constructs bidirectional (upstream / downstream) graph edges based on the nodes and their upstream and downstream relationships in the relationship data table. Graph edges are structures connecting two nodes and represent the relationships between them. This application supports batch import and concurrent writing, lowering the technical threshold and improving efficiency, allowing even non-professionals to quickly migrate data to a graph database without manually writing complex import code or processing data row by row.

[0198] The visualization module 460 visualizes the data in the graph database.

[0199] The visualization module 460 allows users to directly browse and analyze the network relationships within the graph database using visualization tools (such as Neo4j Browser), and periodically synchronizes, validates, or expands the data through automated tools. These visualization tools visually display the data structure through a graphical interface (nodes, edges, attributes), helping users discover patterns, verify logic, or support decision-making. Neo4jBrowser, a built-in visualization tool of the Neo4j graph database, can be accessed directly through a browser and allows execution of Cypher queries, graphically displaying nodes and relationships. Cypher is the query language for the Neo4j graph database, specifically designed for attribute graphs, providing an efficient and intuitive query method.

[0200] This application introduces innovative domain-specific language (DSL) syntax rules that support automatic identification of upstream and downstream relationships, confluence point uniqueness, and node roles, enabling the modeling of complex water system networks (multiple tributaries, confluence points, and diverse cross-section types). Furthermore, it automatically completes cross-section codes and performs uniqueness checks, adapting to actual data management needs. It also features one-stop automatic verification, data structuring, and batch database import, improving the intelligence and efficiency of the entire process, thereby achieving efficient modeling.

[0201] Therefore, this application can greatly improve modeling efficiency, automatically generating and storing dozens or hundreds of nodes and complex multi-level relationships in minutes; improve accuracy, eliminating traditional manual errors such as duplication, omission, and misconnection; automatically verify and capture inconsistent or unreasonable data in advance, reducing manual cleaning and rework costs; be easy to expand and maintain, making it extremely convenient to add new node types or expand to other fields (such as pipeline networks and ecological networks); and have strong compatibility, seamlessly connecting with existing data tables and watershed management platforms, and being compatible with various graph databases.

[0202] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

[0203] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment contains only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A method for modeling upstream and downstream relationships in a water system and automatically mapping graph databases based on a domain-specific language, characterized in that, Includes the following steps: Step S1: Convert the nodes of the water network into DSL text according to the pre-designed domain-specific language; Step S1 includes the following sub-steps: Step S11: Define the mapping of nodes in the water system network to assign a unique node ID to each node in the water system network. Step S12: Using the pre-designed syntax rules of the domain-specific language DSL, describe the upstream and downstream relationships of each node in the water system network by applying the node ID of each node in the water system network. Step S13: Verify the statements describing the upstream and downstream relationships of each node in the water system network according to the predetermined syntax verification rules, thereby obtaining the DSL text; Step S2: Perform automatic completion on the DSL text; Step S3: Automatically validate the autocompleted DSL text; Step S4: Perform relation parsing and data structuring on the automatically validated DSL text to generate node and relation data tables; Step S5: Import the node and relationship data tables into the graph database; Step S6: Visualize the data in the graph database.

2. The method for modeling upstream and downstream relationships in water systems and automatically mapping graph databases based on domain-specific languages ​​according to claim 1, characterized in that, Each node in the water system network is assigned a unique node ID using a mapping dictionary, and the cross-section name of each node in the water system network is specified.

3. The method for modeling upstream and downstream relationships in water systems and automatically mapping graph databases based on domain-specific languages ​​according to claim 1 or 2, characterized in that, Assign a unique node ID to each node in the water network, and also specify auxiliary information for each node in the water network.

4. The method for modeling upstream and downstream relationships in water systems and automatically mapping graph databases based on domain-specific languages ​​according to claim 1 or 2, characterized in that, The upstream and downstream relationships of each node in the water system network are described. The description syntax rule uses a combination of "node type + node ID" and the flow direction identifier "->" to express the flow direction of the water system.

5. A system for modeling upstream and downstream relationships in a water system and automatically mapping graph databases based on a domain-specific language, characterized in that, include: The module includes a DSL text conversion module, an auto-completion module, an auto-validation module, a parsing and data structuring module, an import module, and a visualization module. The DSL text conversion module converts the nodes of the water network into DSL text according to a pre-designed domain-specific language; The DSL text conversion module includes: a node ID allocation submodule, a relationship description submodule, and a statement validation submodule; The node ID allocation submodule maps and defines the nodes of the water system network to assign a unique node ID to each node in the water system network. The relationship description submodule describes the upstream and downstream relationships of each node in the water system network by applying the node ID of each node in the water system network using the syntax rules of the pre-designed domain-specific language DSL. The statement validation submodule validates the statements describing the upstream and downstream relationships of each node in the water system network according to the predetermined syntax validation rules, thereby obtaining the DSL text; The auto-completion module automatically completes DSL text; The automatic verification module automatically verifies the autocompleted DSL text; The parsing and data structuring module performs relation parsing and data structuring on the automatically validated DSL text, thereby generating node and relational data tables; The import module imports node and relation data tables into the graph database; The visualization module visualizes the data in the graph database.

6. The water system upstream and downstream relationship modeling and graph database automatic mapping system based on domain-specific language according to claim 5, characterized in that, The node ID allocation submodule assigns a unique node ID to each node in the water system network using a mapping dictionary, and specifies the cross-section name of each node in the water system network.

7. The water system upstream and downstream relationship modeling and graph database automatic mapping system based on domain-specific language according to claim 5 or 6, characterized in that, The node ID allocation submodule assigns a unique node ID to each node in the water network and also specifies auxiliary information for each node in the water network.

8. The water system upstream and downstream relationship modeling and graph database automatic mapping system based on domain-specific language according to claim 5 or 6, characterized in that, The relationship description submodule describes the upstream and downstream relationships of each node in the water system network. The description syntax rule uses a combination of "node type + node ID" and the flow direction relationship identifier "->" to express the flow direction of the water system.

Images