Formalizing Cross-Parameter Conditions for Geoprocessing Service Chain Validation

Abstract

Geoprocessing operations offered via web services provide the means for building complex web-based geospatial applications. Often, certain postconditions such as the spatial reference system, bounding box, schema or quality that hold on the output dataset after the execution of a geoprocessing service are determined and derived from the properties of the inputs passed to the service. Further, geoprocesses often hold preconditions that relate to more than one input, such as the requirement that all inputs must have the same schema. Within current process descriptions for geoprocessing operations, such conditions which we call cross-parameter conditions, can not be explicitly specified. In this paper, the author gives an approach to formalize such cross input-output and cross input parameter conditions in a rule-based language. Further, the author proposes an algorithm for deriving pre- and postconditions for a service composition or workflow out of the pre- and postconditions of the services involved, allowing a more automated handling of workflows in general.

Formalizing Parameter Constraints to Support Intelligent Geoprocessing: A SHACL-Based Method

“…Existing methods to formalize parameter constraints can be classified into two categories according to the adopted representation language and how they validate input data, namely, inference-oriented methods and query-oriented methods. The inference-oriented methods represent parameter constraints as ontology restrictions (e.g., owl:minCardinality) by using ontology languages (such as the Web Ontology Language, OWL) [13][14][15] and/or inference rules [3,7,8,16] by using rule languages (like the Semantic Web Rule Language, SWRL). Then, the conformities of parameter inputs that have been explicitly encoded as RDF graphs can be validated against these restrictions or rules through logical inferences.…”

“…OWA assumes that the information within a system is incomplete, thus, what has not Currently, most of the parameter constraints are hard-coded in geoprocessing tools and/or documented in their manuals (including extended process profiles of web services [10]). As a result, intelligent geoprocessing relies heavily on end-users' understanding of the tools and trial-and-errors to validate the parameter inputs [2,7,8,12] (Figure 1c). This is frustrating and time-consuming for end-users, especially for non-experts.…”

“…In the last two decades, intelligent geoprocessing based on Semantic Web technologies such as the Resource Description Framework (RDF) and ontology has shown promise to significantly improve the efficiency and effectiveness of the discovery, composition, and execution of geoprocessing tools (especially geoprocessing web services) [1][2][3][4][5][6]. Among the research topics in intelligent geoprocessing, parameter constraints of geoprocessing tools have been increasingly recognized as a key factor in the success of intelligent geoprocessing [2,3,[7][8][9][10].…”

“…J. Geo-Inf. 2021, 10, 605 2 of 24 constraints are important in the discovery and composition of the correct tools to satisfy the goals of end-users or to improve the robustness of geoprocessing workflows [2,3,7,8].…”

“…incomplete, inconsistent, or inappropriate for geoprocessing [3,[9][10][11]. Moreover, parameter constraints are important in the discovery and composition of the correct tools to satisfy the goals of end-users or to improve the robustness of geoprocessing workflows [2,3,7,8].…”