SiBell
commented
4 years ago Been giving this a bit more thought today. I'm wondering if the approach should actually look more like this:
{
"@id": "debcc9ab-3820-4e86-bf2b-d5fa6d5f8002",
"@type": "Observation",
"timeseries": "8j3e92k",
"resultTime": "2020-04-28T11:39:00.000Z",
"hasResult": {
"value": 6.9,
"unit": "DegreeCelsius"
},
"phenomenonTime": {
"hasBeginning": "2020-04-28T11:30:00.000Z",
"hasEnd": "2020-04-28T11:40:00.000Z"
},
"madeBySensor": "thermistor-a7h2",
"observedProperty": {
"@id": "AirTemperature",
"@type": "sosa:ObservableProperty",
"label": "air temperature"
},
"usedProcedures": [
{
"@id": "simple-offset-bias-correction",
"@type": "BiasCorrection",
"label": "bias corrected",
"comment": "A simple constant offset is applied to all values"
},
{
"@id": "5-minute-max-from-1-minute-samples",
"@type": "Maximum",
"label": "5 minute maximum",
"description": "The maximum value over a 5 minute window, is select from 1 minute samples"
}
]
}Key points:
- The generic types, e.g.
Maximum,Average,BiasCorrectionnow apply to the procedures not the observed properties. We could add a query parameter that allows us to filter out any observations with a procedure type we don't want. - By populating the procedures, i.e. including their label and description, you have a nice human-friendly bit of text to show the user exactly what processing has occurred to produce this observation.
- I've added a
timeseriesproperty to the observation. Typically any observations with the same timeseries ID should be shown as a single line on a line graph. You could have an observation that looks exact the same as the one above, except that the 5 minute maximum was instead a daily maximum. This would mean it has a different timeseries id, and could be used to ensure that the value was plotted in a different colour on any graphs. - I'm fully aware that this observation has an awful lot of metadata included, and it may not be practical to include this much information when asking for 100's of observation in one go. This could be where the timeseries approach comes in. You first ask for what timeseries are available, then ask for the stripped down observations for this timeseries (
/timeseries/:timeseriesId/observations). All the observations in a timeseries will have exactly the same values for observedProperty, unit, disciplines, hasFeatureOfInterest, usedProcedures, madeBySensor so there's no point in repeating these in every single observation.
EttoreHector
Many of us will have observations that aren't a simple instantaneous point sample, whether that's because of processing we've done, or this is the only format third-party systems give us the data in. These will be things like maximum and minimum values over a given time frame, or perhaps a mean average. It's important that the end user is aware of this otherwise you run the risk of max, min and average values also being shown together in the same line of a line graph (for example), when really they should be separate lines.
This challenge has been raised before, but following today's technical call I wanted to outline another approach that was discussed. Here's a breakdown of the options available to us:
1. Solely use the
usedProceduresarrayWith this solution the
usedProcedureswould include either"Maximum","Minimum","MeanAverage", etc, when such a procedure has been used. We'd want to keep these consistent across observatories. The end-user or front-end application could then check for the presence of these particular procedures. There could also be some more bespoke, observatory-specific procedures in this array too.N.B. For all these examples the time interval over which the maximum applies is specified using the
phenomenonTimeobject.2. Add an extra
@typeto theobservedPropertyobjectThis was the approach suggested by @lukessmith in today's technical call.
In this approach the
@typeof theobservedPropertyobject becomes an array, because not only is this observed property of typesoaa:ObservableProperty, but we also make it clear that this is a maximum using theuo:Maximumtype. This frees us up to be a bit more specific with our usedProcedure.The downside of this approach is we'll likely need to add another column/property to our database to capture this type.
Other types could be
uo:Minimum,uo:MeanAverage, any more?3. Create completely new observed properties
In this approach I've created a completely new observable property with an id of
AirTemperatureMaximumspecifically for maximum air temperature readings. I've actually kept the extra"uo:Maximum"type, as it provides a nice way to denote which of these new observed properties are maximums, and which are minimums, etc, and this could be defined in the common vocabulary.The downside of this approach is we'd quickly end up tripling the length of observed properties list, potentially duplicating much of what we defined for AirTemperature.