The Problem

Yesterdays post on how I was thinking of implementing monitoring in DIGGSML brought up a lot of discussion in the office! One of the key points made was how are we going to write the descriptor objects (Piezometer, Annometer etc) for EVERY piece of equipment on the market, and what are we going to do when an enterprising instrumentation manufacturer releases a new instrument we've never heard of, and how is the user going to import that data into DIGGSML?! It would be impossible to accurately describe all the instrumentation currently on the market, that's not to mention the continued development the framework would need to enable it's use with any new instruments.

The Solution

We've come up with a new proposal, changing the structure slightly to make a much more generic format for storing monitoring results, the changes aren't very big, but they are very important since they allow anyone to monitor any combination of results for any instrument, past, present or future!

Where we had Annometer and Piezometer in the previous example this has been replaced with a more generic SamplingInstrument object, which contains a name property to define what it is (and even which specific Piezometer instrument).

This SamplingInstrument will contain a new property ReadingGroups, which contains a collection of the groups of reading for this instrument. A piezometer will only contain one reading group, a PositionReadingGroup, since it only monitors one variable. The Annometer will contain two, an AngleReadingGroup and a VelocityReadingGroup. These ReadingGroups in turn contain the readings themselves as before.

 0<instruments>
 1	<SamplingInstrument>
 2		<name codeSpace="http://www.diggsml.com">Piezometer 1</name>
 3		<readingGroups>
 4			<PositionReadingGroup>
 5				<hasCRS>
 6					<Ref xlink:href="crs_bh127"/>
 7				</hasCRS>
 8				<positionReadings>
 9					<PositionReading>
10						<dateTime>2007-01-01T00:01:00</dateTime>
 1						<position>
 2							<gml:pos>1.2</gml:pos>
 3						</position>
 4					</PositionReading>
 5					<PositionReading>
 6						<dateTime>2007-01-02T00:01:00</dateTime>
 7						<position>
 8							<gml:pos>1.2</gml:pos>
 9						</position>
20					</PositionReading>
 1					<PositionReading>
 2						<dateTime>2007-01-03T00:01:00</dateTime>
 3						<position>
 4							<gml:pos>1.0</gml:pos>
 5						</position>
 6						<hasCRS>
 7							<Ref xlink:href="crs_bh127_after_excavation"/>
 8						</hasCRS>
 9					</PositionReading>
30				</positionReadings>
 1			</PositionReadingGroup>
 2		</readingGroups>
 3	</SamplingInstrument>
 4</instrument>

This example shows how the basic structure remains very close to that proposed yesterday, just becoming more generic since the structure of the file is no-longer specific to the type of instrument being monitored.

 0<instruments>
 1	<SamplingInstrument>
 2		<name codeSpace="http://www.diggsml.com">Annometer 1</name>
 3		<readingGroups>
 4			<PlaneAngleReadingGroup>
 5				<planeAngleReadings>
 6					<PlaneAngleReading>
 7						<dateTime>2007-01-01T00:01:00</dateTime>
 8						<planeAngle uom="dega">22</planeAngle>
 9					</PlaneAngleReading>
10					<PlaneAngleReading>
 1						<dateTime>2007-01-02T00:01:00</dateTime>
 2						<planeAngle uom="dega">30</planeAngle>
 3					</PlaneAngleReading>
 4					<PlaneAngleReading>
 5						<dateTime>2007-01-03T00:01:00</dateTime>
 6						<planeAngle uom="dega">27</planeAngle>
 7					</PlaneAngleReading>
 8				</planeAngleReadings>
 9			</PlaneAngleReadingGroup>
20			
 1			<VelocityReadingGroup>
 2				<velocityReadings>
 3					<VelocityReading>
 4						<dateTime>2007-01-01T00:01:00</dateTime>
 5						<velocity uom="m/s">1.34</velocity>
 6					</VelocityReading>
 7					<VelocityReading>
 8						<dateTime>2007-01-02T00:01:00</dateTime>
 9						<velocity uom="m/s">0.23</velocity>
30					</VelocityReading>
 1					<VelocityReading>
 2						<dateTime>2007-01-03T00:01:00</dateTime>
 3						<velocity uom="m/s">2.9</velocity>
 4					</VelocityReading>
 5				</velocityReadings>
 6			</VelocityReadingGroup>
 7		</readingGroups>
 8	</SamplingInstrument>
 9</instruments>

This example is another copy of the example from yesterday, again showing how recording multiple parameters for one instrument is allowed, this allows DIGGSML to cater for all instruments, simply by adding a ReadingGroup for each type of reading the instrument can monitor.

Summary

With such a range of monitoring instruments availiable it would be impossible for DIGGSML to specify an object for each of them, it makes much more sense to implement a generic solution and allow the user to store any number of any type of reading with an instrument. This allows the flexibility to cater for all instruments currently availiable and those yet to be designed and manufactured.