18
2 Research Data Infrastructures and Engineering Metadata
data inventory for unindexed data. Such a role is, for example, the Scientific Data
Officer [9].
• Incentives. On main process to support metadata products is incentives to use
models and tag the data with metadata. These incentives can either be intrinsic or
extrinsic. Intrinsic incentives would include low barriers for metadata annotation.
Extrinsic incentives would include making metadata annotation of the published
research data mandatory for scientific publication.
• Culture. Supporting metadata annotation and also cultural processes have to be
adapted. Metadata annotation and research data management have to be seen as
one essential part of scientific practice. The process of science has to be adapted
to 1. publishing the data Open Access and 2. applying FAIR paradigm of data
description to it. However, this cultural change may be linked to the above process
of incentives. As of now, researchers only get recognition for publishing papers
and not the data.
2.1.2 Metadata for Engineering: The EngMeta Metadata
Scheme
In this subsection, an example for a metadata model and its design will be given.
EngMeta [1, 8, 10] is a semantic metadata standard for computational engineering
and was designed following principles of the above subsection. Following Staab
et al. [5] EngMeta could be referred to as an ontology-based metadata model. A
comparison to VIMMP as a genuine ontology is carried out in Sect. 4.5. EngMeta
was designed as a joint effort of researchers from computational engineering sciences
(process engineering and aerodynamics), from the library sciences as well as from
the computer sciences. This allowed the design of an integrated metadata model
covering all the relevant research aspects in all the four categories as described in
Sect. 1.3.
2.1.2.1 The Object Model of EngMeta
For the design of EngMeta, the object of research had to be identified first. This
seems to be an easy task, but the devil is in the detail.
As aerodynamics and molecular dynamics served as use cases, it was clear that
computational engineering and its outcome were the common ground, but not more.
All the four metadata categories defined in Sect. 1.3 had to be written out with representations, which could only be accomplished by analysing the research itself for
common entities and attributes for process and domain. Both technical and descriptive metadata keys were quite straightforward, since their specificity is low (see
Fig. 1.2). The process metadata and the domain-specific metadata were harder to
carve out from both use cases and could only be gathered by a detailed analysis of
Précédent

- 27/101

Suivant