opengeospatial / sensorthings

The official web site of the OGC SensorThings API standard specification.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Data Quality

securedimensions opened this issue · comments

STAplus entity Group should allow to express data quality.

Use Case

For Citizen Science on air quality, people may install a sensor board for measuring air quality on a bicycle. When driving around, the sensor board measures air quality. In order to calibrate the sensor board, people may pass by reference stations. This could lead to the following scenario:

  • person starts at home driving to the first calibration station: all measurements (observations) are not calibrated. These observations are composed as an observation set into a group.
  • person arrives at reference station and has the sensor board calibrated. This opens a group where all next observations get stored. When arriving at the next reference station, this group is closed and the data quality element is filled with data.
  • person carries on with observations put into next group, etc.

At the end of the bike tour, groups of observations were created where each group expresses the data quality for all comprised observations based on the calibration and other factors. This information on data quality must be stored. But where?

Proposed solution

The STAPlus Group entity shall have a property named dataQuality, which hols a DQ_Element data structure.

DQ_Element is also the type for Observation/resultQuality, so that makes sense.

Objection

I object to the proposed resolution. The inclusion of a DQ_Element without identifying the exact need seems like an overkill. The main use cases for STAplus include Citizen Science and this would imply that the creation of a Group could be done by any user of the STAplus API. Therefore, it would be the responsibility of either the user or the implementer of the app used for the group creation to compute a DQ_Element and serialize it as JSON. But, it seems that there is no official JSON encoding.

Proposed Alternative Solution

Considering that data quality is such a broad topic, I suggest to make the dataQuality property a JSON Object. This would provide great flexibility in describing the data quality for the observations in the group. And, it would not prevent the use of DQ_Element once an official JSON encoding exists.

In my opinion DQ_element should be a JSON_Object in Group as well as in Observation (that can be fixed in 1.2). In the future, I believe we should simplify the dataQuality to the essence. In my opinion 4 parameters could be enough:

  • result (Any)
  • unitOfMeasure (JSON_Object)
  • description (CharacterString)
  • definition (URI)

This is very similar to what we have in the observation+observedProperty

But this should be added to the STA core in a eventual version 1.2 and not in STA+

The dataQuality property of type JSON_Object has been added to the data model.