Modelling of Accuracy, etc

Modelling Accuracies etc (qualitative aspects) -- Result

Modelling Accuracies etc (qualitative aspects) -- Work In Progress

This page is about a way to model the accuracy (and other attributes) of a sensor’s results. This page uses accuracy as the main point of discussion, but then broadens to other attributes (latency, resolution, etc).

It is a work in progress!

Firstly, there seems to be some criteria that should be meet.

- Accuracy needs to be attached to functions, not whole devices or systems, as these could have multiple functions each with different accuracies.

- Accuracy can’t be modelled as a single value or range because it can be dependent on other factors such as current conditions, the inputs, or calibrations. For example, this wind sensor http://www.vaisala.com/files/WM30_Datasheet.pdf has different accuracies depending on the wind speed, and for this one http://www.vaisala.com/files/HMT330_Series_Brochure_in_English.pdf the accuracy is a graph, and here http://www.vaisala.com/files/WXT520_Datasheet_in_English.pdf the accuracy is related to a phenomenon other than the one being measured (the accuracy of Barometric pressure is moderated by temperature). (I know I keep using the Vaisala products for examples, but it’s just the source I’m familiar with that has the most examples)

- It’s not just the case that accuracy depends on physical conditions. For example, resolution might affect accuracy (or field of view affect resolution), or different accuracies might be available for different amounts of energy being spent on the sensing (the Avancha ontology in our review uses something like this to determine a suitable power budget and sensing output). Also different ways of calibrating a device (or wear and tear) will affect its behaviour.

So I see it as a number of factors that could each influence each other.

A way to achieve this is to have a concept of a measurement quality, or range of potential results, that describes the behaviour of a sensor in different conditions. So, in the ontology fragment below, a MeasurementCapability specifies a set of Conditions and the Accuracy, Resolution etc. of the sensor in those conditions.

The remaining problem is to what should this be attached. I felt that while our concept of Process certainly could have quality aspects, it would only ever be part of it as a number of aspects come from implementing the algorithm described by Process. Hence, I added the MeasurmentCapabiliyt, for which a sensor could have many, directly to the sensor.

Here’s an ontology fragment (not including everything from the current ontology, just the relevant bits) showing how this might work.

An Implementation is just something that implements a process

A MeasurementCapability describes a sensor’s behaviour in various conditions

Accuracy describes the accuracy in those conditions

FoV describes the sensors field of view in the conditions

Effect was added to process as a way of describing the actual workings of the process - the mathematical function it implements for example.

Conditions is intended to describe physical conditions or phenomenon relevant to the specification, such as wind speed ranges or temperatures etc.

If we have the idea that a Sensor implements Sensing then it makes sense that there is a class of things called implementations that implement the algorithms or procedures described by Process, though it’s not really necessary.

This modelling of qualitative aspects of a sensors sensor’s operation allows a fair bit of flexibility in modelling multiple accuracies in different conditions, for example. However, it doesn’t yet include some things, such as calibration, wear and tear, and I’m not yet sure how to handle the case of say accuracy expressed as a function of some phenomenon.

Examples

Take the perennial example of the Vaisala WM30 wind speed and direction sensor (http://www.vaisala.com/instruments/products/wm30.html), which for it’s wind speed measurements has the following specification

• Range : 0.5 ... 60 m/s
• Accuracy : ±0.3 m/s (<10 m/s)
• Accuracy : <2% (10 m/s ... 60 m/s)

In the suggested model that would have two specifications for the quality of measurement: one for the condition of windspeed < 10 m/s and the other for windspeed between 10 and 60 m/s. Those two specifications could look like the following (snapped this from some not-quite-valid bits in protege - the point is how the structure can be used rather than how to encode values etc).

The first, just for illustrative purposes, using a fragment of an ontology for values and ranges (abbreviated to make it more readable - the important part is the structure as discussed here and not the values themselves).

The second, this time just in text for a simpler option

The range could be added (this time just in text) as

These three together state the bounds of the accuracy of the sensor in the two wind conditions. They would be part of the Tbox specification of a group of concepts that define the WM30. Instances of this could be added as Abox individuals. The Abox individuals might have for example a location and deployment information, but wouldn’t need to specify anything for accuracy as the existence of this part of the instance's specification is implied by the Tbox definitions above.

Another way this example could have been done is to not use the condition at all and just use range to say “in this range (say, 10 .. 60 m/s) the error is (<2%)”. That works for an example like this where the quality on which the error is dependent is the same as the measured quality, but doesn’t work if they are different: e.g. http://www.vaisala.com/files/WXT520_Datasheet_in_English.pdf where the accuracy of barometric pressure is dependent of temperature.

Example in Top Braid

The example above is now encoded in an owl file (done with Top Braid as per instructions). I've left the above as more info and just include the outline here.

The ontology is attached to this mail message.

It's basically as described above, except the ranges and values are based on the same example done in the MMI Device ontology. Note that the MMI ontology models a particular sensor instance (wind_sensor_wm30_instance_1) using OWL individuals, whereas the example here models the type of all WM30 sensors setting out the accuracy for the whole class using OWL concepts. Thus, using the model from this example, a particular instance of the VaisalaWM30 concept would have this accuracy information without having to specify it explicitly - the MMI example discusses how the same could be done in that ontology.

The ontology has the roles and concepts for measurement capability as described above. It adds a concept for the WM30

and specifies the accuracy of these devices and the conditions in which the accuracy holds

The example shows two ways to specify the accuracy and ranges: without creating any individuals (the first accuracy restriction in the image), and with individuals for accuracy and ranges (the bottom accuracy restriction in the image) as was done in the MMI example and in this case using a nominal, that is a concept that really just represents one individual.

Similar to the MMI example the instances for accuracy and ranges are done by creating Range individuals

and, for example, a MeasurementRange individual

and linking them together. The only real difference with the modelling of this aspect and the MMI example is that here float etc, rather than strings, were used and the modelling of units has been omitted.

The big differences between this example and the MMI one are the difference in the relationship of accuracy, latency etc to each other and that what is modelled here using condition is modelled in the MMI example using a measurement range.

To make the example more complete we could add units of measurement to the values and indicate that the ranges we are talking about are wind speed (as is done in the version above). Though the point isn't to show how these things could/should be encoded, but rather to show how the modelling of accuracy and associated conditions works - i.e. it's just about the model at the top of the page and not ranges, values, uom, etc. In reality units and values should be encoded by including an appropriate ontology modelling those, for this purpose the other parts are more important.

Version 2

Here is a revised version of the model.

It's based on discussions in the 27th April Meeting, I‘ve:

• removed the named roles, and
• added a superconcept for the capabilities

Also:

• Laurent and I discussed linking the MeasurementCapabilities to the qualities they refer to - useful if the sensor measures more than one Quality. With this I would suggest the DL constraint “hasMeasurementCapability o forQuality <= measures”. Note the we don’t yet have anything like “measures” in the ontology - we haven’t yet directly linked sensors to what they measure; it can be done through the observations they can make, but not yet directly. Again the constraint could be something like “INV(procedure) o observedProperty <= measures (we have to be mindful though that there are restrictions on using role composition in OWL2; it’s not a problem for these defs, but it affects how the roles can be used later on).

There isn’t really any difference in what this version of the model and what the one at the top of the page can describe, it’s just down to the names and grouping all the attributes under a common concept. The examples would be the same, with the only exception that any “withAccuracy” etc would be replaced by the one name for all attributes.

MMI Example

Based on the OntDev ontology not the SSN ontology. See MMI example for the modelling of accuracy