# Property-Based Semantic Similarity Criteria to Evaluate the Overlaps of Schemas
## 6 Experiment  
### Computation of Coverage and Flexibility  
Our experiment is mainly compared with the method in [37]. For the neutrality of the experimental results, we select the data of a business practice project of the University of Trento in Italy as the data source. We compared with the original method in [37] which does not consider the weight of entity type in the calculation. In addition, under the premise of considering the weight, we carry out experiments to compare the results of whether to deal with the is-a relationship. The experimental results can verify the effectiveness of the method. The experiment is carried out on a desktop PC with a Intel i7-6700 hq processor, 8 GB DDR4 1333 Ram and SSD hard disk of 900 GB. There are three steps in this experiment. First, we extract entity type and properties from _query_, _datasets_ and _existing universal schema_ to form three schemas. For the convenience of description, these three schemas are referred to as **Query**, **Datasets and **Schema**, **respectively**. The second step is to determine semantically equivalent entity types between the 3 schemas pairwise according to the definitions in Section 4. To simplify the problem, we assume that the semantic equivalence of entity types is symmetric and transitive across schemas. Therefore, we only need to calculate the semantic equivalence of Query-Schema and Datasets-Schema, respectively. Next, we explain the methods of extracting entity types and properties from different schemas. Query is presented in natural language in the project. We manually extracted the entity types contained in Query with the help of the project document. The project document provides some lexical alignment, and because of this, most of the entity types can be judged as semantically equivalent on the label level. However, there are some exceptions. For example, entity type _Company_ extracted from Query and entity type _Business Organization_ from Schema are neither semantically similar nor synonymous in WordNet, but they have the same properties at the property level, so they are computed to be semantically equivalent according to the definition in Section 4. To facilitate the next step of our experiment, standardize all equivalent entity types between Query and Schema. As for Datasets, it is a bit more complicated, because the equivalence of entity types contained in different tables of Datasets must be determined before the comparison with Schema. Therefore, individual-level judgement in Section 4 works. For example, entity type _Company Category_ and entity type _Industry_ from 2 different tables have the same individuals and these two entity types are semantically equivalent according to the definition in Section 4. After entity type equivalence judgment and standardization, the numeric relationship of Schema, Query and Datasets in our experiment is found, as shown in Figure 6. The overlapping parts represent the equivalent entity types. For example, the number \"9\" in the blue part in Figure 6 indicates that nine equivalent entity types can be found in Query, Schema and Datasets, and the \"8\" in the yellow part indicates that there are 8 equivalent entity types in both Query and Schema. The third step of our experiment is to calculate the weights of all entity types in Datasets and Schema by the method proposed in Section 5. Limited by space, we cannot list all the results. Figure 7 shows the distribution of entity type weights. We divide these entity types into six important degrees according to a step size of 0.02 and use them as independent variables of the experiment. Figure 6: Equivalent entity types across schemas. It can be seen from Figure 7 that most entity types in Schema are of low importance. Only a few important entity types have high weights. Three computation methods were involved in our experiment:  
1. The method which does not consider property-based weight computation (classical method in [37]);
2.