Open dr-shorthair opened 1 month ago
Currently the spec makes use of the ad-hoc ssn, sosa, sampling and ssn-system namespaces for referencing terms. On one hand this keeps things tidy. On the other, terms from all 4 namespaces are needed to represents a real-life sensor which then asks why we split them in the first place.
Option one: Move everything from ssn-system to the sosa / ssn namespace.
Option Two: Reorganize operating classes.
Currently ssn-system organizes as follows:
It may make sense to reorganize it so that
ssn-system:OperatingRange
is a subclass of ssn-system:SurvivalRange
under the common sense view that normal (sustainable) operating conditions are also survivable operating conditions.
A side benefit is the reduction in the number of specialized "utility" properties hasSurvivalProperty / hasOperatingProperty.
Option Three: Reuse system characteristics for ssn-system:qualityOfObservation (Would answer #221)
Currently ssn-system:qualityOfObservation
has no range but is a subproperty of ssn:hasProperty
which implicitly allows the use of sayssn-system:Accuracy
. This wouldn't change anything from an ontology perspective but we can document it as a practice:
This allows for the Observation to report results quality using the existing system properties and handle both fault or out-of-range situations where the result is "unknown but above 100C". Should we consider allow a reference to changed OperatingRange or Condition?
Option Four: Leave everything "as-is". However we need to review some of the examples which make use of the wrong system properties and we need one BatteryLifetime examplar.
Definitions for terms such as 'accuracy', 'precision', 'resolution', 'repeatability' must be consistent with the VIM
Here's a few for starters:
closeness of agreement between a measured quantity value and a true quantity value of a measurand
NOTE 1 The concept ‘measurement accuracy’ is not a quantity and is not given a numerical quantity value. A measurement is said to be more accurate when it offers a smaller measurement error.
NOTE 2 The term “measurement accuracy” should not be used for measurement trueness and the term “measurement precision” should not be used for ‘measurement accuracy’, which, however, is related to both these concepts.
NOTE 3 ‘Measurement accuracy’ is sometimes understood as closeness of agreement between measured quantity values that are being attributed to the measurand.
closeness of agreement between indications or measured quantity values obtained by replicate measurements on the same or similar objects under specified conditions
NOTE 1 Measurement precision is usually expressed numerically by measures of imprecision, such as standard deviation, variance, or coefficient of variation under the specified conditions of measurement.
NOTE 2 The ‘specified conditions’ can be, for example, repeatability conditions of measurement, intermediate precision conditions of measurement, or reproducibility conditions of measurement (see ISO 5725-1:1994).
NOTE 3 Measurement precision is used to define measurement repeatability, intermediate measurement precision, and measurement reproducibility.
NOTE 4 Sometimes “measurement precision” is erroneously used to mean measurement accuracy.
measurement precision under a set of repeatability conditions of measurement
smallest change in a quantity being measured that causes a perceptible change in the corresponding indication
NOTE Resolution can depend on, for example, noise (internal or external) or friction. It may also depend on the value of a quantity being measured.
Will send PR for this shortly.
For this morning's telecom
The current system-capabilities module is large and largely untested/unused.
230 proposes moving it to a separate document.
However, some basic capabilities (measurement-range, accuracy, precision, sampling-rate) are common, and probably merit retaining in the core of an ontology with 'sensor' in its name.
@oldskeptic to prepare a proposal.