search

urbanobservatory / standards

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

Feature of Interest #8

Open SiBell opened 5 years ago

SiBell commented 5 years ago

Is there benefit in deciding on a common set of FeatureOfInterest's.

I'd say keep these really generic, e.g. use the terms already on Newcastle's data portal, such as Air Quality, People, Weather.

The combination of FeatureOfInterest and observedProperty potentially gives us a powerful way of filtering the data. I.e. "give me all observations with FeatureOfInterest=weather and observedProperty=ThermodynamicTemperature".

lukeshope commented 5 years ago

I agree. It also looks like you're only allowed the one FeatureOfInterest.

We might have to consolidate some of the categories on the Newcastle portal slightly. Perhaps...

Not sure about 'earth' or 'noise'. Better ideas?

SiBell commented 5 years ago

The more thought I give this the harder it becomes!

Technically speaking air quality, water quality and noise may actually be observedProperty's. Therefore is something like this better:

Although Pollution isn't much better, too negative?

aarepuu commented 5 years ago

I had a think about this as well and these are my ideas:

What do you think?

SiBell commented 5 years ago

I'd be happy with weather going under atmosphere. I think we need to make sure that indoor atmosphere is in a different category to outdoor atmosphere though.

SiBell commented 4 years ago

Is it worth adding another featureOfInterest for diagnostics? I.e. for observations of a device's battery voltage, or its RSSI (signal strength).

EttoreHector commented 4 years ago

I guess it really depends on who are / are going to be the main users of our data platforms. Such a feature of interest is mainly relevant to maintenance staff. For what I can see there's nothing wrong having that feature been represented, but I wonder whether we can think of any reasons why it shouldn't (maybe security reasons of any kind..?) In general I believe our data solution cannot be the perfect deal for all possible scenarios of data use.

On Fri, 25 Oct 2019, 10:25 Si Bell, notifications@github.com wrote:

Is it worth adding another featureOfInterest for diagnostics? I.e. for observations of a device's battery voltage, or its RSSI (signal strength).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/urbanobservatory/standards/issues/8?email_source=notifications&email_token=AB6X6YJXHLN2BUQIEGXUIGLQQK3SPA5CNFSM4HY6422KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECHYWII#issuecomment-546278177, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6X6YMLR2OGXWWX3MNMYJTQQK3SPANCNFSM4HY6422A .

SiBell commented 4 years ago

It's a very good point. It almost makes the argument stronger for having a diagnostics featureOfInterest, at least at the database level, so that you can choose to filter out any observations of this type if the request has come from a member of the public.

lukeshope commented 4 years ago

I'm in favour of having something like that, though I would prefer to think of it as condition rather than diagnostics, if it's things such as signal strength, battery level, remaining rocket fuel, transmission rates, etc.

I think the security risks associated with RSSI or battery level are negligible, but there's no reason you can't restrict the observation and/or observation collection associated with the sensor if need be, while still describing the metric. You would just return a 401/403 status code for those parts of the graph.

EttoreHector commented 4 years ago

I am somehow still confused about the definition of FeatureOfInterest and ObservedProperty. If I stick with what I read in https://www.w3.org/TR/vocab-ssn/#SOSAFeatureOfInterest and https://www.w3.org/TR/vocab-ssn/#SOSAobservedProperty, I'd be tempted to say that

However, from what we discussed in this thread and from what I can see in Simon's examples (https://github.com/urbanobservatory/standards/tree/si-edits/api/ontology-examples) it should be more like:

What would be the best way to go around?

SiBell commented 4 years ago

So my take on it was that many of the examples in the SSN Docs the FeatureOfInterest is some physical thing e.g. an office, apartment, Atmosphere of Earth, a window, a tree, etc. In the interest of saving us from having to agree on dozens of different features of interest, we're veering towards some very top-level, broad features, e.g. 'utilities', 'atmosphere', 'hydrology', etc. I'd agree that 'Air Quality' isn't a good name for a FeatureOfInterest and 'Earth Atmosphere' is probably better for this.

The examples for observedProperty are things like CO2, temperature, battery, windSpeed, so I'd say that no2-concentration would fit in nicely with these and be a valid observedProperty. If you can have {observedProperty: 'windSpeed', hasFeatureOfInterest: 'atmosphere'}, i.e. the speed of the wind is an observed property of the atmosphere. Then I don't see why we couldn't have {observedProperty: 'no2-concentration', hasFeatureOfInterest: 'atmosphere'}, i.e. the concentration of NO2 is an observed property of the atmosphere.

We could really do with deciding on the definitive list of Urban Observatory FeatureOfInterest's and ObservableProperty's soon so that we don't end up with one observatory using no2-concentration and another NO2level.

lukeshope commented 4 years ago

I agree with what Si says. I think it's helpful with the ObservedProperty to make them as precise as possible, so for example air temperature rather than temperature, and NO2 concentration rather than NO2. In other words, enough specificity in the name to be able to know if you're comparing apples and oranges.

I suppose atmosphere is probably sufficient for things like air quality, unless any of the UOs are planning on going extraterrestrial?

I suspect the FeatureOfInterest and ObservableProperty lists will need to grow organically, as we buy new sensors and integrate new systems. Perhaps we should pick an easy(ish) category to begin with (like meteorology) and then we expand on it through pull requests and discussion, when there are no obvious candidates?

EttoreHector commented 4 years ago

Thank you both.

On Tue, 21 Jan 2020 at 16:32, Luke Smith notifications@github.com wrote:

I agree with what Si says. I think it's helpful with the ObservedProperty to make them as precise as possible, so for example air temperature rather than temperature, and NO2 concentration rather than NO2.

I suspect the FeatureOfInterest and ObservableProperty lists will need to grow organically, as we buy new sensors and integrate new systems. Perhaps we should pick an easy(ish) category to begin with (like meteorology) and then we expand on it through pull requests and discussion, when there are no obvious candidates?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/urbanobservatory/standards/issues/8?email_source=notifications&email_token=AB6X6YPHYHZFEPLHVUBKNRLQ64PTHA5CNFSM4HY6422KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJQL3AY#issuecomment-576765315, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6X6YKP52T5C6DSO7QFPHLQ64PTHANCNFSM4HY6422A .

SiBell commented 4 years ago

I agree it'll end up growing organically. Let's get an initial list up in the docs, and then, as you say, use pull requests and discussion to add more when we need to.

If we do go extraterrestrial then this would be the time to add a new feature of interest, e.g. Space.

I'd say Meteorology is probably a bad name for a feature of interest given the early discussions about features of interest being more physical things. Therefore atmosphere would be better.

Taking this into account and merging our suggestions above, should we start with the following:

N.b. happy to merge utilities into infrastructure for brevity.

lukeshope commented 4 years ago

Ah yeah, good point, bad example on my part.

I think all of the above makes sense for APIs where they only have sensors, and no contextual information about what those sensors relate in terms of rooms of a building or road junctions.

In some cases though, we will have a proper featureOfInterest. For example, a temperature sensor in a room might have a platform that is the wall (as represented in a BIM model for example), but the featureOfInterest would be the room (as represented in a BIM model as a space) rather than infrastructure.

If we have a "proper" featureOfInterest, should we attach the above "themes" using another relation? Either the sensor could be a member of a collection that represents the theme, or we could use theme from DCAT.

The above all sounds like a sensible fallback for when there is no more precise featureOfInterest, or in the case of weather stations, where they're measuring the external environment.

SiBell commented 4 years ago

Totally see your point. A key factor is scale. My features of interest work well when looking at a city as a whole, asking questions like: "what's the average indoor air temperature across Birmingham", but less so for local scales: "is the average temperature of room G7 warmer than room G8 in the Urban Sciences building".

The way I've been handling this scale issue with what I've coded up so far is using nested platforms. So an example observation would be:

{
  resultTime: "2020-01-22T22:17:09.124Z",
  hasResult: {
    value: 22.6
  },
  madeBySensor: "thermistor-abc",
  observedProperty: "air-temperature",
  featureOfInterest: "infrastructure",
  isHostedBy: ["urban-sciences-building", "room-g7", "north-wall"]
}

The urban-sciences-building is itself a platform, which hosts room-g7, which also hosts the north-wall which hosts an air temperature sensor.

It's then really easy to query for any observations from the "urban-sciences-building", and just as easy to just get observations from the "north-wall".

It's a tricky one because the urban sciences building in this example is both a:

  1. host for sensors, therefore fitting the definition of a platform.
  2. a feature of interest for anyone analysing the building.
SiBell commented 4 years ago

At some point soon I'll begin storing observations alongside a given featureOfInterest and observedProperty, so I've had a very quick look around for any pre-existing lists of quantites that I could use as the observedProperty. I think I've hit the same problem that Ettore was alluding to earlier that existing quantities are very generic, e.g. "thermodynamic temperature" not "air temperature". E.g. here and here.

If we go down the route of having a more specific observedProperty values then it looks like we'll need to maintain our own list.

SiBell commented 4 years ago

If we used these quantities as the observedProperty and these disciplines as the featureOfInterest does that work?

The issue I see is, for example, when you have a quantity of Temperature and featureOfInterest of Meteorology you have to rely on an assumption that the temperature must be of the air, e.g. rather than a ground temperature.

SiBell commented 4 years ago

So my previous suggestion was a terrible one, it doesn't take long to find an example that won't work.

For example rain gauge accumulation observations would end up being something like {"observedProperty": "Height", "featureOfInterest": "Meteorology", which doesn't even tell you it's rain!

I think we're best maintaining our own list, e.g. with observedProperty's of rain-accumulation and rain-rate, but can always use the QUDT quantities and disciplines as a starting point.

SiBell commented 4 years ago

It might be of interest to see the approach that this paper takes.

SiBell commented 4 years ago

Here's a whopping great big list of Meteorological and Atmospheric Chemistry variables that could be used as ObservedProperty's.