Requirements for Geospatial Ontology Engineering

ion geospatial domain ontology Figure 2: The distinction between three types of concepts leads to geospatial domain ontologies which are not biased by implementation needs. For example, a town is often represented as a point feature in geospatial applications. But in the first place, the “real world” town has no ontological relation to the representational structure of a point. The domain of geospatial concepts should thus be strictly separated from the domain of data representations. If towns are modelled in an application by representing them as points, then this relation between town and its geometrical representation will be part of the application ontology. This view is also reflected in Figure 3, where the domain concepts and representation concepts are distinguished by their colourings. The requirement of keeping geospatial ontologies independent from the implementation view is also a strong argument for introducing a layered ontology architecture as shown in Figure 4. Geospatial Sub-Domains In the definition above, a distinction is made between concepts for real world geospatial phenomena and concepts for representing them. Defining the scope of the latter ontologies is relatively simple as they are based on existing models for implementing geographic information, e.g. the specifications of the Open Geospatial Consortium (Lemmens & Vries, 2004; Probst et al., 2004). In contrast, defining the extent of a geospatial ontology is much more difficult since ontologies on the domain level claim to comprise the basic concepts of a common conceptualisation. Great care must be taken to define the concepts and relations on an appropriate level of expressiveness. The terms have to be general enough to allow the annotation of all information sources, but specific enough to make meaningful definitions possible (Schuster & Stuckenschmidt, 2001). In consequence, geospatial ontologies require to be defined within a certain context and for a well-known user community, i.e. we have to come up with adequate and manageable subsets of the geospatial domain. Moreover, to serve as source for building application ontologies, the domain ontology needs to meet the requirement of high stability. This is, the ontologies should reach after an iterative development phase a status comparable to a standard. Frequent changes in the domain ontologies would discourage service providers to reference their application ontologies on them. Internal Ontology Structure The structure of efficiently applicable geospatial ontologies has to meet the requirements of the semantic matchmaking approach in the example. Taxonomic reasoning is useful but not sufficient. Equally, or more important are non-taxonomic relationships, e.g. that a quantity has a unit of measure. Consequently, we need ontologies that describe not only simple taxonomic relationships but provide suitable axioms to express other relationships between concepts and to constrain their intended interpretation (Guarino, 1998). Non-taxonomic relationships play a central part in ontology engineering and should be used wherever possible for defining concepts (Hart, Temple, & Mizen, 2004; Lutz & Klien, 2005; Tomai & Kavouras, 2004). This strategy leads to domain ontologies, which contain not only taxonomic but also non-taxonomic relationships. Figure 3 depicts extracts from domain ontologies for Measurements and Hydrology. In this ontology, taxonomic as well as non-taxonomic relations are defined. Thus, a concept does not have to be given a fixed position in a static hierarchy. Rather, its position in the hierarchy can be dynamically inferred based on existing concept and role definitions using subsumption reasoning. This is fundamental for enabling the ontology-based search for unknown information sources. Some guidelines for the formalisation of domain ontologies are proposed in (Lutz & Klien, 2005).