ObservingProcedure

[mbeaufils]

As defined in OMS :

The description of steps performed in order to determine the value of an observableProperty by an Observer.

NOTES: 1) Depending on the complexity of the use case, the procedure will be more or less explicitly described. Especially pertaining to historical data, there may be very little or no information available - this information should also be provided; 2) The recipe that the observer (cook) follows to generate the observation; 3) The procedure is often referred to as the method; 4) Different observers can follow the same (reusable) procedure for the creation of different observations; 5) The procedure is a workflow, protocol, plan, algorithm, or computational method specifying how to make an observation; 6) The observing procedure cannot describe a sensor instance, but it can describe the sensor type. NOTE The term process that was used in ISO 19156:2011 has been purposely dropped in this version to avoid unnecessary confusion between the terms procedure and process.

EXAMPLE An instance of Procedure is a description of the process utilized by an observer, this could be a chemical analysis method, a protocol for measuring an object, but could also be a checklist utilized by a human observer during a biodiversity campaign. Procedure could further describe the algorithms behind simulators or models used to generate a result from other inputs.

An Observation SHALL have exactly 1 observingProcedure.

[LucasoilCloud]

I agree that the procedure has to be recorded for each observation. Maybe for simplifing we could only indicate the standard used for the acquisition of the observation. For example ISO 22476-3 for SPT test.

For the fun, I have checked the wikipedia page for the SPT test and it is indicated 'The test procedure is described in ISO 22476-3' so implicitly that means that if we indicate the standard, we have the procedure.

[mbeaufils]

Ideally the description of the procedure should be freely accessible.

[LucasoilCloud]

Why not. So the procedure has to be considered as a 'string' type property of an observation. The value can be a standard reference or anything else.

[dponti]

All observations result from some procedure, but I think we need to be careful not to create a schema/model that requires the reporting of a procedure for every observation. In working/using legacy data, sometimes information on the process that leads to a result is lost or was never documented. While not having this information may compromise or limit the utility of the results, depending on the use case, but it doesn't necessarily render the result useless.

[mbeaufils]

An observation is associated to 1 ObservingProcedure

[mbeaufils]

@dponti and other people that would like to propose a definition of a process. A proposal from the OGC standard SensorML exists. It worth been considered: http://docs.ogc.org/is/12-000r2/12-000r2.html

For your information, SensorML is a usual buddy for OMS ;-)

[dponti]

Below is a proposed start at a UML model for a Geotechnical Process (GT_Process). This object is intended to be the object that is referended by the Observation's procedure property. Following I'll give some encoding examples. The intent of this model is to accommodate pretty much any kind of chain of complex procedural observations that are then used to determine the observation's "result". The process can contain a chain of "procedures" each one of which can have any number of nested "procedural observations". Metadata is handled by the parameter property, which uses OM's NamedValue object. The ProceduralObservation derives from GML's AbstractCoverage which allows for all of the 4 observation typologies we evaluated earlier within a single structure.

Note, I've looked a bit at SensoML's process structure but need to see examples of how a process chain is encoded and how the inputs and outputs work together. @mbeaufils do any examples of this exist? The examples included with the schema are pretty poor. Would be worthwhile to see if this model can be conformed to the SensorML model

[dponti]

Attached are encoding examples of GT_Process for a Lugeon test procedure and a Partlcle Size test procedure using the above model in JSON notation (my apologies for any screw ups as my JSON skills are poor). I'm more comfortable in XML but this might be more readable. The extra nesting is due to conformance with GML's object-property rule. LugeionExample.txt ParticleSizeExample.txt

[mbeaufils]

BRGM registry: https://data.geoscience.fr/ncl/_Proc

This includes Procedures identified by the MINnD project + others that are not necessarily associated to Geotechnics.

[dponti]

The below diagram lists the test (observation) procedures currently supported in DIGGS. The procedural attributes are (mercifully) omitted here. Attached, however is a spreadsheet that lists the observed properties for observations (sheet Definitions) and the procedures associated with these result properties (sheet AssociatedElements) DIGGSTestPropertyDefinitions.xlsx

[mbeaufils]

Thanks @dponti. Also I like the listing of the Properties per Procedure.

Is these ObservedProperties (meaning the Procedure ALWAYS address those properties) or ObservableProperties (meaning the Procedure CAN address those properties)?