urbanobservatory / standards

Standards and schema documentation for the observatories programme
2 stars 0 forks source link

How to deal with sosa:Observation sosa: hasResult :sosa:result #6

Open EttoreHector opened 5 years ago

EttoreHector commented 5 years ago

It was suggested that each Observation should only store one Result, i.e. Result should also be an object, rather than an array.

Two questions:

  1. We probably don't want to create a triplet sosa:observation sosa:hasResult :result everytime we get a new reading from a sensor. Should the object of the triple just point to an endpoint that provides the last reading of the sensor?

  2. Shall we provide a predicate such as uo:hasDataSeries that will point to an endpoint providing the last, say, 24h readings (unless a different time-span is specified)?

lukeshope commented 5 years ago

Hi Ettore,

You're right, there are some real issues with the original SSN vocabulary for data series, and I appreciate what you're saying about having easy access to the latest sensor observation.

Because the timestamp is part of sosa:Observation, I think we're more likely to have a collection of sosa:Observations than an array of sosa:Results under one sosa:Observation, but it looks like the standard does allow multiple results under one observation (not sure what the use case is for this?).

I think we need to use the SSN extension vocabulary which provides ssn-ext:ObservationCollection.

Access to the latest observation Keen to avoid introducing our own vocabulary terms if we can use existing and widely accepted ones to explain the same.

The simplest way I can think of would be using hydra:last as an additional type on the observation. We could provide a link to this, in addition to an ssn-ext:ObservationCollection.

GET https://example.com/sensor/a

{
  "@context": {
    [...],
    "lastObservation": {
      "@id": "sosa:madeObservation",
      "@type": ["sosa:Observation", "hydra:last"]
    },
    "allObservations": {
      "@id": "sosa:madeObservation",
      "@type": ["@id", "ssn-ext:ObservationCollection"]
    }
  },
  "@type": "sosa:Sensor",
  [...],
  "lastObservation": {
    "@id": "https://example.com/sensor/a/no2-concentration/observations/2019-05-31T19:45:00Z",
    "sosa:resultTime": "2019-05-31T19:45:00Z",
    "sosa:observedProperty": {
      "@id": "https://example.com/property/no2-concentration"
    },
    "sosa:hasResult": {
      [...]
    }
  },
  "allObservations": "https://example.com/sensor/a/no2-concentration/observations"
}

Providing a fixed time window by default Not sure how to go about this one. I wonder if we should make things simple for ourselves and go for fixed size pages, so you get the last 100 observations by default, and pagination links allow you to get to the rest.

If we do want to offer the last 24 hours by default, serving the ssn-ext:ObservationCollection should be easy enough if we add schema:startTime and schema:endTime to the response, but the link to the collection should probably contain something to indicate the time window too (i.e. some indication it's a 24 hour window relative to the current time).

Open to better ideas... :-)