# Ontology-Based Spatial Data Quality Assessment Framework
## 3 Discussion  
### Case Study  
The case study revolves around the basemap of Trabzon province, which has been extracted and tailored to conform to the Turkish Large-Scale Map and Mapping Production Regulation. The dataset consists of building, cadastral parcel, and road layers among others, for the quality assessment.  
Figure 10. provides a visual depiction of the study area along with the specific layers that have been selected for implementation. Layers' information for the case study is summarized in Table 8 below.  
The selected layers play a crucial role in the analysis and application of the regulations, enabling a comprehensive assessment of spatial data quality within Trabzon province. For the case study, the following topo-semantic rules are determined from the regulations listed below.  
\begin{table}
\begin{tabular}{l l l} \hline \hline
**Layer** & **Number of Features** & **Size** \\ \hline Road & 4395 & 2.3 MB \\ \hline Building & 20,596 & 5.7 MB \\ \hline Cadastral Parcel & 33,641 & 18.2 MB \\ \hline \hline \end{tabular}
\end{table}
Table 8: Overview of layers for the case study.  
Figure 10: Map of Trabzon city center, a section of the study area.  
* Necessary-type rule, \"Buildings must be within a cadastral parcel\".
* Forbidden-type rule, \"Rads must not cross over buildings\".
* Forbidden-type rule, \"Cadastral parcels must not self-overlap\".
* Forbidden-type rule, \"Buildings must not self-overlap\". are the rules used for the case study.  
Figures 11 and 12 show examples of inconsistent features in the case data that violate the given rules. Building data are represented in gray, cadastral parcels are depicted in yellow, and road data are shown with red lines. An example of the \"Necessary\"-type rule is depicted in Figure 11. In Figure 12a, a building that overlaps other buildings is repainted red (less opaque) for visualization. Similarly in Figure 12b, a building is repainted light yellow.  
The given rules were used to create the SfO ontology. The selection and creation of an SfO follows these steps:  
* If the user, in this case, domain expert, is aware of the appropriate SfO for their domain, they can directly utilize that SfO.
* If SfO is not found in the system, the user is prompted to create a new SfO. This process involves using the SfO creation interface.  
The creation of an SfO requires domain experts with expertise in the specific domain and its specifications. For each SfO, three essential components are generated: a Turtle file containing the ontology, an R2 RML mapping file for data transformation, and a post-reasoning complete CSV file that summarizes the ontology. The rules are implemented through the GUI as follows to create the SfO:  
* Buildings must be within cadastral parcel: Necessary sfWithin:  
Figure 11: A building that is not within a cadastral parcel.  
Figure 12: Examples of “Forbidden”-type rules in the use of case data: (**a**) Overlapping buildings and (**b**) Roads crossing over buildings.  
\"c2,c2,Necessary,sfWithin,Building, Cadastral_Parcel, timestamp_value\"
* Buildings must not overlap: Forbidden sfOverlaps, same class: \"c2,,Forbidden,sfOverlaps,Building,, timestamp_value\"
* Roads must not cross buildings: Forbidden, sfCrosses: \"c1,c2,Forbidden,sfCrosses,Road,Building, timestamp_value\" This process ensures that the resulting SfO aligns with the domain's requirements and effectively represents the spatial data quality constraints and relations.  
The SfOs are created with the GUI. They can be modified with the GUI or an ontology editor. Removing specification rules corresponds to removing generic classes corresponds. Most changes in the specification correspond to changes in subclass relations.