Other queries to provenance
Copyright © 2014 Open Geospatial Consortium.
41 require a better understanding of how information was generated. This way, the system
can support request such as:
Show in the map only features or attributes that originated in the USGS dataset.
o
This query refers to sources involved in the conflation process.
Show in the map only features or attributes that originated in government datasets.
o
This query asks about types of sources involved in the conflation process
Show in the map only features or attributes that were conflated by 52N.
o
This query asks about agents involved in the conflation process.
Show in the map only features or attributes that were conflated by a particular conflation algorithm.
o
This query asks about entities involved in the conflation process.
Show in the map only features or attributes that were conflated by a particular conflation rule, like distance threshold.
o
This query asks about entities involved in feature and attribute level conflation processes.
Show in the map only features or attributes that were conflated before Jan 1, 2014.
o
This query asks about characteristics of the conflation process, in this case their execution date.
Show in the map only features or attributes where the original USGS dataset and the OSM dataset were in agreement.
o
This query asks about information contained in the sources involved in the conflation process.
A better understanding of the kinds of provenance queries that need to be supported for a given application would determine the appropriate design for a provenance solution,
since different solutions have storage and performance tradeoffs as discussed in Section 5.5. Requirements in terms of provenance queries, both technical and user driven, are left
for future work. As an example of how to drive user requirements, a possible demonstration scenario
involving provenance would be to show in a user interface a panel the results of a specific set of provenance queries such as the above. For example, a panel with all the original
source datasets dynamically extracted from the provenance records of the conflation processes and as the user selects one source then all the points in the map that have
featuresattributes from that data source would be highlighted in green and the points where information from that data source was not selected by the conflation would be
highlighted in red. The development and implementation of such scenarios is beyond the scope of the work on OWS-10, and left for future work.
42
Copyright © 2014 Open Geospatial Consortium.
10 Storing provenance using XML
One of the problems that has the implemented approach discussed in Section 7 is the need to store the provenance in one encoding RDF and stored in a database triple store
that is deferent from the encoding GML and the database WFS used for the geospatial data.
A priori, the use of an XML encoding seems to be more appropriated to generate a more homogeneous environment where all information can be stored in the same format. In the
end, we will see that we need 2 independent services anyway and the final architecture is not so different.
This approach was elaborated at the beginning of the OWS 10 activity is included in this document for completeness. It was never implemented and discarded in favor of the
RDF approach previously discussed. We think there is a value on describing the progress made and allow the reader to decide which approach fit better with its use case. Section
11 briefly compares both approaches and the argumentation used to decide in favor of the RDF approach to provenance.