# Property-Based Semantic Similarity Criteria to Evaluate the Overlaps of Schemas
## 5 Computation of Coverage and Flexibility
### Weight  
Before the definition of weight, let us take the schema (Figure 2) extracted in Figure 1 as an example (hereinafter referred to as **schema A**). There are four entity types in schema \(A\) [_student_, _teacher_, _course_, _scholarship_] and four object properties {_receive_, _take_, _teach_, _lecture_} between these four entity types. Among these four entity types, _student_ is associated with the other three entity types, while _scholarship_ is associated with _student_ only. Suppose there is another schema referred to as \(B\) containing entity type {_teacher_, _course_, _scholarship_} without entity type _student_. Entity type _student_ in schema \(A\) is not covered by schema \(B\). The consequences brought by this mismatch are relatively serious because the absence of entity type _student_ will lead to a lack of connection between entity type _student_ and other entity types, which will easily lead to the incomplete and inaccurate phenomenon when we use schema \(B\) to cover schema \(A\). Semantically, if entity type _student_ is missing in schema \(B\), _Cov_(_A_, _B_) should be lower in this case. In another case, if schema \(B\) contains the entity type {_teacher_, _course_, _student_} without entity type _scholarship_, it means that schema \(B\) can cover all entity types in schema \(A\) but entity type _scholarship_. This kind of incompleteness will not affect the relationship between other entity types because _scholarship_ is associated with _student_ only. That is to say, the negative impact is relatively small, so the computation result of _Cov_(_A_, _B_) should be greater than in the previous situation. Similarly, suppose there is a schema C containing entity type {_teacher_, _course_, _scholarship_ without entity type _student_. Now we need to calculate the redundancy degree of schema \(A\) after it covers schema C, that is, _Flx_(_A_, _C_). There is no entity type _student_ in schema C while entity type _student_ is very important in schema \(A\), which means that entity type _student_ in schema \(A\) is very redundant. That is, schema \(A\) has serious redundancy. Therefore, _Flx_(_A_, _C_) is large. On the contrary, if schema C contains entity type {_teacher_, _course_, _student_} without entity type _scholarship_, the redundancy degree will be relatively low. Additionally, _Flx_(_A_, _C_) should be smaller than in the previous situation because redundant entity type \(A\) in schema C is not as important in schema C.  
According to the example above, the intuition is that different entity types should be associated with different weights according to their relationship with other entity types. In a schema, the relationship between entity types is related to object properties. We use \"property\" for \"object property\" if no ambiguity exists. Next, we introduce the definition and quantitative calculation method of entity type weight based on property. Definition 2: Weight of Entity type  
In a schema, the weight of entity type \(E\) is  
\[weight(E)=\frac{|L_{E}|}{2*|L|} \tag{4}\]  
Figure 2: Schema \(A\) extracted from Figure 1.  
where \(|L|\) is the total number of all properties between all entity types in the schema. \(L_{E}\) is defined as follows:  
\[L_{E}=\{\text{p}|E\in domain(p)\text{ or }E\in range(p)\}\]  
\(|L_{E}\mid\) is the cardinality of \(L_{E}\). There are two exceptions to mention. Firstly, the entity type without any property is difficult to express in a schema, so we do not consider these isolated entity types. Secondly, in the denominator of weight definition \(|L|\) needs to be multiplied by 2 because the property p is calculated twice in the definition \(L_{E}\). This process ensures the normalization of weights, that is, the weight of each entity type is less than 1 and the weight sum of all entity types is \(1\), \(\sum_{i=1}^{n}|L_{E_{i}}|=2*|L|\) (n is the total number of entity types in a schema). In order to make this formula easier to understand, we use the entity types in schema \(A\) in Figure 2 as an example.