Design of a logical data exchange model

We now introduce the design of a logical data exchange model by adapting our published article [17]. As a canonical data model at the logical level, the logical data exchange model is about to design a logical structure that is simple and abstract enough to enable the data in different FSP data models to be exchanged. Therefore, it should be a generic structure for FSP data organization.

Being a data model abstracting structure and function of plants, the logical data exchange model itself can also be created by data modeling based on the analysis and abstraction of plant structures in the real world. Similar to the other FSP data model, the focus should be on the structure, as “structure is the basis of function;

function is the performance of structure”. In essence, there are two levels of requirements for designing a logical data model for abstracting plant structure. The first is the syntactic level, which is the basic level for every kind of data models and which refers to how the elements of data may be organized and accessed. As a plant structure model, some important characteristics of plants need to be taken into account: (1) plant components normally emerge and grow based on existing

components; (2) nutrients reach a component after going through a path consisting of preceding components that are physically connected; (3) also the amount of components and interconnections changes constantly during the whole life cycle of the plant. Because of these characteristics, the elements of plant architectural data are highly connected and codependent with a high rate of change. This demands a data model with high efficiency of update such as insertion and deletion of elements of data.

Apart from the requirements at syntactic level, expressive relationships between elements of data representing dependencies between plant components are biologically meaningful. To automatize various types of biological reasoning, the meaning of the dependencies should also be captured. This leads to the requirement on the semantic level, and demands a data model capable of capturing the semantics of the dependencies/relationships between elements of plant architectural data.

In addition, FSPMs distinguish between function and structure of plants and regard the structure as the basis of the function. Hence, the way organizing elements of architectural (topological or geometric) data of the expected data model needs to be syntactically and semantically different from functional elements. In other words, the architectural data elements are required and the functional data elements are optional. The functional data elements are attached to the architectural data elements. The semantic relationships representing adjacency (i.e. biological dependency) between plant components exist only between architectural data elements.

Structured data models, such as the relational model, do not meet these requirements [145]. The reason is that for elements of plant architectural data, these models are capable of a high efficiency when responding to queries, but have difficulties to capture the semantics of the dependencies, and suffer from a low efficiency update. On the other hand, some semi-structured data models do not distinguish between different elements of data. There is no concept of some

elements of data having more precedence, or importance, over other elements, e.g.

properties of a resource are also resources in the Resource Description Framework (RDF) [146], and thus these kinds of data model do not meet the requirement.

The development of plant data models demonstrates an evolution from specific architectural models for specific plant structural modeling, via generic architectural models for structural modeling, to generic FSP data models for FSP modeling. The MTG and RGG graph are two typical data models that are currently widely used and accepted as standards for FSP data modeling, and they are the target data models of our project as well. Hence, the detailed comparative analysis between MTG and RGG graph is helpful to get a logical data exchange model enabling the exchange of FSP data between MTG and RGG graph.

From the facts shown in the detailed comparison of the MTG and RGG graph on both design and implementation introduced in the second chapter, some common elements were discovered and abstracted. At design level, the two data models in their current version are both multi-scaled, with the support of three types of adjacency to abstract the neighboring relationships between modules of real plants.

For the MTG, the within- and inter- scale topology are both rooted trees, while the overall topology is a rooted graph. For the RGG graph (i.e. three-part-graph), particularly the instanced graph, the within-, inter- scale, and overall topology are all rooted graphs. Therefore, the topology of the RGG graph is the more general and was considered as the topology of the logical data exchange model. At the implementation level, both MTG and RGG graph are a combination of property graph and scene graph, but with opposite primary/secondary relationship and other specific settings, e.g., geometric data elements can only be represented as properties of graph nodes in the MTG, transformations without other (functional) properties.

Thus the logical data exchange model considers the same combination but with no primary/secondary relationship and no specific settings. Topologically, a property graph is a scene graph with properties attached to nodes and edges. For the logical

data exchange model that considers only the topology, the abstraction from the implementation level is thus the “general” or “original” property graph.

The property graph is a type of semi-structured data model distinguishing nodes and their properties. In these logical models or graphs, nodes and edges are used for representing the elements of architectural data and relationships respectively. This makes insertion and deletion of nodes very easy and fast, and ensures a high efficiency update. Moreover, different types of relationships are defined to explicitly describe the meanings of the relationships, so the data model becomes a semantic network and automatic reasoning can be carried out through relationship paths for computing biological variables. Besides, functional data elements are optional and attached as properties of a node of the graph. This guarantees that the architectural data element takes precedence over the functional elements. The property graph meets all the requirements and suits well for the specific focus of corresponding methods abstracting plant architecture, except the capability of multiscale modeling. Consequently, the logical data exchange model should be the combination of the multi-scaled rooted graph and the property graph, with three types of adjacency to abstract the neighboring relationships between modules of real plants. There should also be an unambiguity property for nodes, i.e. id as the unique identifier of a node, as well as for edges, i.e. id as the unique identifier of an edge, source id as the id of the node where the edge starts, and target id as the id of the node where the edge ends. Unlike the MTG and RGG graph, which have their own specific modeling focus, the designed logical data model does not have a specific focus, so that it is able to function as a data exchange model adapting all the logical variants of rooted multi-scaled property graphs.

On one hand, we derived a logical property graph model by specializing the conceptual property graph with some constraints that exist in both MTG and RGG-based graph, or by generalizing MTG and RGG-RGG-based graph. Figure 4.4 illustrates two basic types of components, i.e. Nodes and Edges that are directed and labeled

with a “Type” denoting the type of relationship between their source and target nodes. The arrowheads indicate the direction of edges. Both Nodes and Edges have

“Ids” in Arabic or Roman numbers and can be associated with properties, which are “key: value” pairs in italics. The key refers to the property id and the value is the property of a particular node or edge. In addition, we added some constraints for the properties, as illustrated in Figure 4.4 [17], two properties “Name” and

“Type” which are associated to each node, and the “Type” property attached to each edge that allows a value set including the three standard options (succession, branch, and decomposition). With the additional semantic features, we enhance the ability of our data exchange model to adapt to heterogeneous plant architectural data.

On the other hand, we propose a logical data model of a conceptual data model

“Rooted Graph” [147] [148] with specific constraints. The reason is that we have observed that many applications have a distinguished node serving as entrance node Figure 4.4 Logical property graph model [17]

to their graphs. Figure 4.5 [17] shows our logical rooted graph that is a directed graph in which one single node has been distinguished as the root node (illustrated by a dashed circle). All the other nodes are connected directly or indirectly with the root node. This root node is a special node that does not correspond to any plant architectural component in the real world, but represents the whole plant (or the coarsest scale) for multiscale data.

By combining the logical property graph and the logical rooted graph, setting the id of the root node as “root_id” with the fixed value “0” and prohibiting having properties of the root node, we get our targeted logical data model EG (Exchange Graph), as shown in Figure 4.6 [17].

Figure 4.5 Logical rooted graph model [17]