ObservableProperty

[mbeaufils]

As defined in OMS :

A quality (property, characteristic) of the feature-of-interest that can be observed.

EXAMPLE 1 The height of a tree, the depth of a water body, or the temperature of a surface are examples of observable properties, while the value of a classic car is not (directly) observable but asserted.
EXAMPLE 2 Groundwater Level
On a groundwater well we:
a) Monitor Groundwater Level (1 observable property)
b) With an automated probe (that remains in the ground all year, constituting 1 procedure).
Then we have physical campaigns where we revisit the groundwater well and:
— Measure the Groundwater Level (still the same observable property as above)
but
— With a manual probe, this is a different procedure.
This allows for checking whether the probe needs recalibration.

[mbeaufils]

An observation is associated to 1 ObservableProperty

[mbeaufils]

Looks like we have here an interesting list of relevant ObservableProperty in Geotechnics: https://www.diggsml.org/dictionaries/DIGGSTestPropertyDefinitions.xml

[mbeaufils]

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

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

[neilchadwick-dg]

A list from AGS (v4.0.4 - the new v4.1.1 would give an even bigger list).

This is derived from taking all of the AGS headings, then reducing down to those dealing with in situ or lab 'tests'. There are many 'readings' obtained from the fieldwork itself, but these are not included. I then filtered out anything that was clearly location data, other test metadata, or 'common' types of 'result/reading' such as 'remarks', 'environmental conditions' etc.

I may have deleted some things I should not have. Conversely I may have left in a few that do not belong. Consider this just a starting point. It gives a flavour of the 'challenge'.

I also left out anything to do with monitoring, contamination or soil chemistry (AGS already adopt a codelist approach for these - and those lists are ... you don't want to know !)

Use the 'Test results' sheet. Other sheets for background only.
Reported results from AGS 4-0-4.xlsx

[mbeaufils]

Thank you @neilchadwick-dg, for providing this. Again a huge list of terms that shows a lot is already existing.

One comment:

• I have the impression that MINnD and DIGGS were "Observed/Observable Properties driven" and then list the procedures that can lead to their obtention,
• While AGS seems to be "Procedure driven" then same observed/observable properties would then appear with different names / codes depending on the procedure they come from.

[neilchadwick-dg]

Yes, you are probably correct. It is an accident of history - it just evolved that way.

But if there is some rationalisation then we do have to make sure that the procedure - property link is strong. If the 'procedure' goes missing then the outcome could be misleading data.

e.g. an undrained shear strength from a pocket penetrometer is very different from a triaxial derived undrained shear strength on a 100mm specimen, which is turn is different from a triaxial undrained shear strength on a 38mm specimen.

AGS may indeed be inefficient in this respect, but at least we ensure that people know what they are getting!

[Didymograptus]

• While AGS seems to be "Procedure driven" then same observed/observable properties would then appear with different names / codes depending on the procedure they come from.

The AGS was developed primarily by contractors, trying to replicate the data that was reported on BH logs and on summary lab test report sheets. So yes it originally document-driven . It's why for example we have fields in the LOCA group that only include final depth of the BH and status of the information (e.g. prelim) rather than status of the activity (e.g. in progress).

I think that this is an important distinction to understand when looking at the properties spreadsheet. Are we documenting the properties of activities, or reports (artifacts) or both?