After Monitoring and the SamplingPoint object - Part 3 we had reviewed various methods of encoding blocks of tabular data in XML and identified a number of previous implementations of this construct (WITSML, SensorML).

This article details how DIGGSML builds on the implementations in WITSML and SensorML and implements a generic Table structure for storing lots of repeating Monitoring data.

After Monitoring and the SamplingPoint object - Part 2 we left the Monitoring section of DIGGSML in a workable state.

There is however a problem associated with this method, it's verbosity, adding a large amount of data will rapidly produce a prohibitively large file.

This article details how this problem arises and two possible solutions, using a space separated lists of values, and using a tabular system proposed by John Bobbitt of the Petrochemical Open Standards Consortium (POSC) as well as taking looking at the OGC's standard for this type of data, SensorML.

As of Friday 10th August 2007 DIGGSML v0.9 has been released for internal review.

See inside for a comprehensive list of changes and instructions on how to obtain this release.

Yesterday I posted a suggestion on how I was thinking of implementing monitoring in DIGGSML, after some consultation we have decided to make some changes! This is a new proposal (which supercedes the previous one), with a much more generic structure. Allowing DIGGSML to cope with monitoring devices and instrumentation that we don't currently use (indeed may not even be manufactured yet!) is very important as it would be impractical to update the framework every time a new instrument was marketed.

This article details a new implementation of Monitoring, allowing DIGGSML to transfer monitoring data for any number of parameters, with any number of readings, for all pre-exisiting instruments and any that may arise in the future.

Here's one proposal for implementing Monitoring In DIGGSML, using a SamplingPoint object, it sits alongside the Hole and FoundationGroup objects inside a Project. This post will explain the structuring of the proposed SamplingPoint object, it's contained Instruments (both single and multiple reading), their associated readings and how to record one or many readings from the same instrument.

Please note that the information contained in this article is now superceded by the article located Here