16
2 Research Data Infrastructures and Engineering Metadata
Fig. 2.1 Example of component entity, which has several attributes, such as the smilesCode and is
a part of the simulated target system, which is shown by a relation
Figure 2.1 shows how a component in materials modelling could be represented
by an entity, some attributes and a relation according to the example given above.
All the entities can then be categorized according to the proposed classes of Sect.
1.3. The component entity would be categorized as discipline-specific metadata.
Also in this step, the question arises if the description needs to be data centric
or process centric. It strongly depends on the research process how to answer this
question. For example, in code development, one needs to continuously follow the
changes made to the codes, i.e. the process of programming. Hence, the appropriate
description of programming can only be process centric.
1 In data science applications, it is strongly dependent on the workflow, if a data-centric or a process-centric
description should be chosen. In general, if data is the main outcome, even in a
chain of process steps, one might want to choose a data-centric approach. If the processes are central to the research endeavour, and each process has a discrete output,
one might chose a process-centric description. Of course, both approaches are not
mutually exclusive. A data-centric approach also includes process information and
a process-centric approach an elaborated description of the data. It is just a matter
of hierarchical structuring and precedence. In Sect. 2.1.2, we will discuss why and
how we decide for a data-centric model for computational engineering and realized
in EngMeta.
1 This is reflected by tools such as git, which include metadata for every commit to describe the
process.
2 Research Data Infrastructures and Engineering Metadata
Fig. 2.1 Example of component entity, which has several attributes, such as the smilesCode and is
a part of the simulated target system, which is shown by a relation
Figure 2.1 shows how a component in materials modelling could be represented
by an entity, some attributes and a relation according to the example given above.
All the entities can then be categorized according to the proposed classes of Sect.
1.3. The component entity would be categorized as discipline-specific metadata.
Also in this step, the question arises if the description needs to be data centric
or process centric. It strongly depends on the research process how to answer this
question. For example, in code development, one needs to continuously follow the
changes made to the codes, i.e. the process of programming. Hence, the appropriate
description of programming can only be process centric.
1 In data science applications, it is strongly dependent on the workflow, if a data-centric or a process-centric
description should be chosen. In general, if data is the main outcome, even in a
chain of process steps, one might want to choose a data-centric approach. If the processes are central to the research endeavour, and each process has a discrete output,
one might chose a process-centric description. Of course, both approaches are not
mutually exclusive. A data-centric approach also includes process information and
a process-centric approach an elaborated description of the data. It is just a matter
of hierarchical structuring and precedence. In Sect. 2.1.2, we will discuss why and
how we decide for a data-centric model for computational engineering and realized
in EngMeta.
1 This is reflected by tools such as git, which include metadata for every commit to describe the
process.