16
Copyright © 2014 Open Geospatial Consortium.
Figure 7 —OGC concepts in W3C PROV
All these triples are stored together in the file 0_Prov_OGC_RDF.n3 that can be found in Annex B.
In W3C PROV, entities can have additional attributes, and even a location. In W3C, entities are the things that have provenance information associated with them. This work
addresses also attribute level provenance. To do so, feature properties need to be also considered entities. Even if this could not be strictly necessary, we also want to record the
relation between properties and the features they are characterizing. We also wanted to emphasize that a feature has geometric and non-geometric properties because in many
cases geometric properties are collected with different techniques than non-geometric so the provenance information will be different.
A geometric property is a subclass of entity
ows:Geometry rdfs:subClassOf prov:Entity .
Points, Lines and Polygons are subclasses of Geometry
ows:Point rdfs:subClassOf ows:Geometry . ows:Line rdfs:subClassOf ows:Geometry .
ows:Polygon rdfs:subClassOf ows:Geometry .
A non-geometric property is a subclass of entity for notation simplification purposes, we assume that a Property is non geometrical property:
ows:Property rdfs:subClassOf prov:Entity .
Properties geometric and non-geometric need to be related to features. W3C PROV does not have the needed kind of relation. For that reason, we define this relation from
scratch.
A feature can have geometric properties by declaring that hasGeometry:
ows:hadGeometry a owl:ObjectProperty ; rdfs:comment A geometric property of a resource ;
rdfs:domain ows:Feature; rdfs:isDefinedBy http:www.opengis.netogcowsows-core-
ontology ; rdfs:label hasGeometry ;
rdfs:range ows:Geometry .
Copyright © 2014 Open Geospatial Consortium.
17 A feature can have non-geometric properties by declaring that hasProperty:
ows:hadProperty a owl:ObjectProperty ; rdfs:comment A Non geometric property of a resource ;
rdfs:domain ows:Feature; rdfs:isDefinedBy http:www.opengis.netogcowsows-core-
ontology ; rdfs:label hasProperty ;
rdfs:range ows:Property .
All this triples are stored together in the file 0_Prov_OGC_RDF.n3 that can be found in Annex B.
6.2 Feature identifiers and namespaces
Every entity needs a name in W3C PROV. In particular, features need names. The simplest method to obtain an identifier is using a name inspired in the feature id e.g.
gml:id escaping all none allowed characters in the selected notation e.g. “.”s are converted to “_”s. These names are unique in the dataset and so they need to be in a
namespace that represents the dataset.
For instance a feature with an id “road.66” in the “usgs” dataset will be defined as
prefix usgs: http:www.usgs.govusgs_dataset1 . usgs:USGS_Map1 a ows:FeatureCollection .
usgs:USGS_Feature rdfs:subClassOf ows:Feature . usgs:road_66 a usgs:USGS_Feature .
Nevertheless, the name restrictions in the RDF turtle notation does not allow us to use the exact same name than in other encodings such as gml:id’s, so we need to set some
equivalences. One possibility is to use a full URL to get the feature from a WFS request or a GML document.
USGS_Map1 owl:sameAs http:portal.cubewerx.comcubewerxprojectsows9cubeserv.cgi?service
=WFSamp;datastore=OWS9amp;request=GetFeatureamp;typename=usgs:fireSt ationEmsStation .
usgs:road_66 owl:sameAs http:portal.cubewerx.comcubewerxprojectsows9cubeserv.cgi?service
=WFSamp;datastore=OWS9amp;request=GetFeatureamp;typename=usgs:fireSt ationEmsStationamp;GetFeatureById=road.66 .
Another way to relate the rdf name to the feature id e.g. gml:id we could also do this.
prefix gml: http:www.opengis.netgml . usgs:road_66 gml:id road.66
18
Copyright © 2014 Open Geospatial Consortium.
7 Applying W3C PROV to the conflation process case
To describe the conflation process implemented in OWS-10, we use a modular approach and divide the problem in 6 layers: from the most general and abstract concepts, to the
more specific and exact executions in OWS-10. Each layer is defined in different namespaces.
Figure 8 — W3C PROV Provenance Conflation Diagram showing the 6 layers see the legend in the modular approach and all the relations between objects see it magnified in
Annex A.
magnified in Annex A shows all abstract elements in the upper layers and some samples of individual features and attributes. The 6 layers are:
The upper layer layer 0 describes the general OGC concepts explained in Section 6.2: includes the abstract WPS service, the abstract WPS operation and
how they are related to the W3C PROV concepts. These concepts are also shown in the topmost layer and come directly from the W3C PROV owl definition ogc
namespace.
The WPS Conflation Profile layer layer 1 defines a generic conflation WPS, connecting it to a generic conflation algorithm and providing the list of input and
output parameters and their roles. This is, in fact, what in OGC is called a WPS profile for conflation described in OWS-7 Web Processing Service Profiling
Engineering Report ows10 namespace.
The layer 2 describes the concrete conflation process developed by 52North. Thus, in this example: the 52N Conflation WPS, which is a concrete WPS service
and uses the specific algorithm of 52Nf2n namespace. This is the user layer layer 3, where the person or the agent who executed the
process in this example, the NGA organization is defined nga namespace. The layer 4 defines the conflation session parameters that is a sequence of
conflation steps: the datasets the sources maps and the conflated map and the generic concept of a distance are described and related each dataset has its own
namespace, resulting in 3 namespaces in the example.
In the conflation use case, the user is supervising conflation steps that involve a set of a few features and, for each step, we are documenting the features and
attributes participating in it layer 5 each feature in each dataset has its own namespace, resulting in 3 namespaces in the example.
