## 4 Semantic Management Component
### Get MappingSuggestion Service  
The \"getMappingSuggestion\" provides mechanisms to map two data models. The goal of the service is to identify how close the concepts in one model are interrelated to concepts in another model. The result of mapping, as mentioned above, can be reused for further reasoning or discovery. In Figure 3, the models submitted for mapping are identified as input, which is a JSON document containing both models. From now on, we use the terms \"origin\" and \"target\" to identify the two parts of the input data model, as also shown in Figure 3. It is important to mention that the \"getMappingSuggestion\" service is developed for use within the vf-OS framework; thus, it has a structure based on JSON format. This is necessary to represent, if needed, the data models as a complex, structured tree of concepts with appropriate relations. In order to better understand the involved models, we introduce the metastructure of the input models (Figure 3). These models comprise several fields as follows:  
* \"label\"--which introduces the name of the capillary/single concept;
* \"tag\"--this field can be used to identify the attributes of the concept. The inspiration for introducing the \"tag\" field came from the topic of folksonomy, described in [43], where a collaborative tagging system is presented that is composed of three core entities: users, resources, and tags. Tags, compared to, for instance, resources, are in no way limited by predefined vocabulary [44]. In this work, tags are used to describe the concepts that, to some extent, can be compared with resources in folksonomy;
* \"xpath\"--is used to show the parent concepts of the capillary/single concept. This field allows expressing the hierarchy of concepts from a specific concept to the root;
* \"type\"--used to express the type of the concept, for instance: string. Figure 3: General schema of the input data models for getMappingSuggestion. The input file containing the origin and target models is delivered to the harmonization component, which is responsible for correct communication with the graph DB, proper parsing, and integration of the input data model. In order to clarify the process of delivering and mapping the data, we use definitions derived from the set theory and graph theory. The payload, or, in other words, data within the origin and target models, is represented as two sets:  
\[\text{M}_{\text{S}}=(A,T_{S},Xp_{S},Type)\text{ \emph{and} }\text{M}_{\text{T}}=(B,T_{T},Xp_{T},Type), \tag{1}\]  
where \(\text{M}_{\text{S}}\) stands for the origin or source data model, and \(\text{M}_{\text{T}}\) stands for the target. Subsets A and B contain the capillary concepts derived from the \"_label_\" field. The related concepts from the \"_path_\" and \"_tag_\" fields are expressed through the \(\text{T}_{\text{S}}\) and \(\text{T}_{\text{T}}\) terms and \(\text{Xp}_{\text{S}}\) and \(\text{Xp}_{\text{T}}\) subsets. And finally, the \"_Type_\" subset represents the variety of types of concepts from A and B subsets. As the graph DB deals with nodes and relationships, all data being part of the input are converted. Thus, the concepts become nodes and relationships that are generated according to the data model schema. The data model schema assumes that all concepts from the fields \"_tag_\" and \"_xpath_\" are directly related to the concept presented in the \"_label_\" field (Figure 3). After the concepts provided in the origin and target models are inserted and converted into nodes, and appropriate relationships are created, the phase of data mapping starts. As mentioned in Section 2, the pathfinding approach for mapping follows the [PERSON] algorithm implemented as the APOC.algo extension of Neo4j [45]. It supports calculation of the \"distance\" considering the weights of the path segment. This is important in order to cope with requirements for the weighted approach stated in Section 2.