# Ontology-Based Spatial Data Quality Assessment Framework
## 2 Materials and Methods
### Framework
#### 2.3.3 Spatial Data Quality Ontology  
In a country, a multitude of institutions can exist that create and handle the very same spatial data, repeatedly, with questionable quality, to comply with the regulations of each institution and central authorities. Institutions need to assess the quality of the data they create or query the quality of the data they receive. This is the main problem that we intend to solve with the help of SDQO within the proposed framework. Figure 3: Ontology interaction. Figure 2: Spatial data to RDF conversion. For the design of the SDQO, several points are considered following a literature review, primarily focusing on concepts related to data quality and rule types within the spatial quality domain. Spatial and attribute rules classified as 'forbidden' and 'necessary' are identified based on the examined regulations. One example of a \"necessary\" type of spatial rule is that \"Any building must be within at least one parcel\". \"A road must not cross over a building\" is an example of a \"forbidden\"-type rule. In addition to determining which rule types to use, we select questions for the ontology to answer. Some of the identified competency questions are as follows:  
* Which features have a particular set of data quality problems? * Which features have topo-semantic problems with the specified ones? * Which features have domain consistency problems? * What is the number of erroneous objects in the tested data? For OWL ontologies, the top class is owl:Thing. Within the SDQO ontology, sdqo:Data QualityElement, sdqo:DataQualityResult, and ogc:SpatialObject are the direct subclasses. The ogc:SpatialObject class, the main class of GeoSPARQL, further branches into two subclasses: ogc:Geometry and ogc:Feature. Within the SDQO ontology, the ogc:Feature class has three distinct direct subclasses, in addition to those imported from other ontologies. These subclasses are sdqo:ResrictedFeature, sdqo:GeomClassifiedFeature, and sdqo:FixedRefFeature, as visualized in Figure 4.  
An SWRL rule is utilized to automatically assign any feature to the appropriate subclass within sdqo:GeomClassifiedFeature, based on its dimension and the ogc:asWKT value of its geometry. The sdqo:GeomClassifiedFeature class encompasses three subclasses: sdqo:CalcLine, sdqo:CalcPoly, and sdqo:CalcPoint. This information proves useful, for instance, in verifying the correct declaration of dimensions. The sdqo:FixedRefFeature class includes OWL-named individuals that can serve as reference markers in rules. These reference individuals can be employed, for example, in attribute tests. Under sdqo:RestrictedFeature, there exist four subclasses. The descriptions of these classes can be found in Table 3.  
Figure 4: Main classes of SDQO ontology mapped with GeoSPARQL. The sdqo:InterObjectPrRF class encompasses classes of features that have standardized spatial relations as object properties. This type of classification ensures generalized ontology modeling. Consequently, a domain-independent design is achieved. sdqo:InterObjectPrRF has several pairs of classes, for example, sdqo:ClassCross1 and sdqo:ClassCross2. These classes are superclasses of the classes in the corresponding SfOs. For example, if there is a rule in the specification such as \"Contours must not cross buildings and lakes\" This rule is implemented in the SfO by creating required classes for \"cannot cross rule\". As SfO imports SDQO, it establishes additional subclass relationships between the classes. For instance, if so:Contour is a subclass of sfo:ClassCrf01 and sfo:Building, sfo:Lake, and its subclass sfo:PermanentLake are subclasses of sfo:ClassCrs01, the associated rules will infer that features of type sfo:Contour cross features of any of the other mentioned classes. Moreover, these rules will generate more detailed results regarding these occurrences, highlighting the violation of the specification rule stating that \"contours must not cross over buildings and lakes\". Figure 5 shows the ontological correspondences of the \"must not cross\" rule.