Generating OWL instances from the feature/annotation model and apply SWRL spatial built-ins
Ok, let's try to summarize this idea. We parse a file with domain references into our Feature Model with annotations. The model reference basically says that we have feature type instances (~ features) which represent real world features commonly described using the concept from the domain ontology. Example: A GML file with features having linestrings as geometries is semantically annotated with the domain concept River (since this is a level 1 annotation, we can deduce that _all_ features in this collection represent rivers). Let's say we have additionally another KML file which features Points of Interests, including cities. This time the individual placemarks are linked to domain concepts which describe the type, e.g. city, monument, and so on.
The task: Find all cities which lie next to a river. This means we need some kind of query language which takes both, the spatial and the semantic dimension of the features into account. Fortunately, we have the Semantic Web Rule Language (SWRL). But we have two things to before we can solve the task using SWRL. First, since we are working now with logical reasoners, we also have to transform the features into a objects which can be processed by the rule-enabled reasoning engine. We have to transform our features (including their geometries) and the annotations into OWL instances (memberOf gml:FeatureType). Secondly, we have to provide implementations of the spatial checks. In our task, we need an method which checks if one geometry touches another. Let's call this built-in SWRL function spatial:touches(?x,?y) which requires two instances of gml:Geometry as input. Once we have the instances and the SWRL function, we could simply solve the task (this is of course a guess ;) using the following expression:
// there is an instance of a feature type "ftA" which is annotated with river River(?x) ^ domainReference(ftA,?x) ^ // the same for city City(?y) ^ domainReference(ftB, ?y) ^ // features have geometries hasGeometry(ftA, ?a_geom) ^ hasGeometry(ftB,?b_geom) ^ // geomtries are adjacent, this invokes our implementation spatial:touches(?a_geom,?b_geom) // we want to find the city --> query:select(ftB)
Ok, what's the catch
- we can apply selections across all different file formats supported by our spatial streaming library. One query selecting features from KML, Sensor observations, and a WFS on the same time
- support across the annotation levels (may be, this implies that one feature collection includes semantically similar features, e.g. only rivers)
- a reasonable use for spatial built-ins
- most probably not with good performance. Transforming hundreds of GML features into instances takes a while, applying rules as well. Requires therefore tweaking.