"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Discussion: Geochemical Analyses

O&M delivers geochemical analyses of geological specimens (eg: whole rock XRF analyses, borehole assay intervals, soil sample analyses). In these cases the sa:SampledFeature is a gsml:GeologicUnit (whether its name is known or unknown). The O&M rules say that the om:ObservedProperty must be a direct or indirect property of the FeatureOfInterest. Currently neither GeologicUnit nor EarthMaterial has a suitable geochemical composition property (CompositionCategory is not appropriate).

There is general agreement about using O&M to describe sampling, and analytical and processing procedures. What we need to work out is what goes after om:Observation/om:result/.....?
    • omx:Measurement/gml:measure ?
    • Are SWECommon elements (such as DataRecord, DataArray) useable for encoding tables of geochemical data? (see CGIValueAndSWEComponentDiscussion)

Also, how do we encode errors/precision. ISO DataQuality? But is this GML 3.2 dependent? Maybe SWECommon data quality?

Examples of some existing schemas for geochem/geochron analyses (for information):

EarthChem (October 2008) - not OGC-based

<EarthChemSample xmlns="http://geoportal.kgs.ku.edu/earthchem/schema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://geoportal.kgs.ku.edu/earthchem/schema file:/C:/oraymond/GeoSciML_Model/catalog_home/earthchem/earthchem_v26.xsd" sample_id="olr_189465b" samplenumber="76324" source="My_thesis">
  <Geography>
    <Location>
      <Point>
        <coord>
          <X>145</X>
          <Y>-45</Y>
          <Z>10</Z>
        </coord>
      </Point>
    </Location>
    <Location_Precision>34</Location_Precision>
  </Geography>
  <EarthChemData schematype="earthchem">
    <Citation journal="AJES" year="1978">
      <Title>My Paper on Rhyolites</Title>
      <Author>Fred Bloggs</Author>
      <Sampletype>
        <Phase>
          <ROCK>
            <class1>igneous</class1>
            <class2>volcanic</class2>
            <class3>felsic</class3>
            <class4>rhyolite</class4>
          </ROCK>
        </Phase>
        <Material materialtype="whole rock">
          <method name="XRF">
            <item group="chemical" name="SIO2" type="major_oxides" qualityrank="excellent" value="69.83" units="WT%"/>
            <item group="chemical" name="AL2O3" type="major_oxides" qualityrank="not_bad" value="6.78" units="WT%"/>
            <item group="chemical" name="CAO" type="major_oxides" qualityrank="fair_to_middling" value="4.56" units="WT%"/>
          </method>
        </Material>
      </Sampletype>
    </Citation>
  </EarthChemData>
</EarthChemSample> 

EarthTime (October 2008) - like O&M, draft only (from Steve Richard)

EarthTime_Oct08.jpg

Geoscience Australia (built on O&M and GeoSciML - draft only)

2009-09-10_CM-_RaGInG_SPOT_OM_and_GeoSciML2.jpg

A possible O&M encoding?

<sa:GeologicSpecimen gml:id=”My_rock_sample”>
  <om:relatedObservation>
    <omx:Measurement>
      <gml:name>Ag</gml:name>
      <om:samplingTime/>
      <om:procedure>
        <om:observationProcess gml:id=”Ag_ICPMS_process”>
         <om:method xlink:href="urn:ICPMS/>
         <om:resultQuality>
          <DQ_QuantitativeAttributeAccuracy>
            <result>
             <DQ_QuantitativeResult>
              <valueUnit xlink:href=”urn:UCUM:ppm”/>  
              <errorSatistic>2 sigma</errorSatistic>
              <value>3</value>
             <DQ_QuantitativeResult>
            </result>
          </DQ_QuantitativeAttributeAccuracy>
         </om:resultQuality>
      </om:procedure>
      <om:observedProperty xlink:href="urn:AnalyteConcentration"/>
      <om:featureOfInterest xlink:href="HandSpecimen_1234"/>
      <om:result>
        <gml:measure uom="urn:UCUM:ppm">13.6</gml:measure>
      </om:result>
    </omx:Measurement>
    <omx:Measurement>
      <gml:name>Pb</gml:name>
      <om:samplingTime/>
      <om:procedure>
        <om:observationProcess gml:id=”Pb_ICPMS_process”>
         <om:method xlink:href="urn:ICPMS/>
         <om:resultQuality>
          <DQ_QuantitativeAttributeAccuracy>
            <result>
             <DQ_QuantitativeResult>
              <valueUnit xlink:href=”urn:UCUM:ppm”/>  
              <errorSatistic>2 sigma</errorSatistic>
              <value>1</value>
             <DQ_QuantitativeResult>
            </result>
          </DQ_QuantitativeAttributeAccuracy>
         </om:resultQuality>
      </om:procedure>
      <om:observedProperty xlink:href="urn:AnalyteConcentration"/>
      <om:featureOfInterest xlink:href="HandSpecimen_1234"/>
      <om:result>
        <gml:measure uom="urn:UCUM:ppm">79.8</gml:measure>
      </om:result>
    </omx:Measurement>
  </om:relatedObservation>
</sa:GeologicSpecimen> 


A record of an email thread regarding O&M and geochemical data, May 2009

How is “gsml:material” (the observedProperty) a property of “sa:SamplingPoint” (the FoI), to satisfy the O&M spec?

Ollie Raymond 11 May 2009-09-18


O&M allows exactly this kind of transitivity. The relevant constraint says 'observed property must be member *or component of member* of feature of interest". That means it can be a property of a property of the proximate fOI - i.e. a property of the sampled feature.

Simon Cox 11 May 2009


Yes, I got that. When a sample is the fOi, we are refering to the property of the sampledFeature. I was pointing out that Ollie's LocatedGeologicSpecimen (in the UML) has a explicit property to geochemicalComposition /AnalyticalSuite, and I though this was a problem.

Eric Boisvert 11 May 2009


This 'problem' has been the subject of a number of comments, most recently and formally at the O&M SWG in Athens. It led to a formal comment being submitted by OGC to ISO recommending that the constraint be relaxed. I'm hearing this from so many places it is going to be hard to resist.

So, not sure how the word-smithing will go, but it is likely that O&M v2 will allow esentially arbitrary properties to be observed, with the intention that they be related to the fOI somehow ...

Simon Cox 12 May 2009

(end email thread)

To comply with EarthChem requirements to provide citation details with geochemical data, links CI_Citation would be required. However, can only use MD_Metadata elements if we implement GML3.2 services

Ollie Raymond 22 Sep 2009


Geochemistry detection limits, instruments, methods

A record of an email thread between October 2009 and February 2010

Hi Bruce

I have some data from the Laterite Geochemical Database from the Yilgarn Craton, WA http://catalogue.nla.gov.au/Record/4229094 http://www.csiro.au/science/ps3g5.html

I was wondering what standards or proposed models existed which I could massage the data into? Who are the best people to chat to about the model? Are there any other sites providing information in these formats?

Terry Rankine -- 26 Oct 2009


Hi Terry,

I've finally found some time to map the Yilgarn regolith geochemistry database to the O&M model.

I've attached a draft of the instance document with lots of comments. I'm sure some of this is wrong so I invite comments and suggestions from the other GeoSciML Geochemistry Task Group. I hope you don't mind that I have forwarded your URLs to the database.

I've also attached an excel spreadsheet showing the mapping between the database table fields and the XML.

Like most things in O&M there are multiple ways of attempting this mapping. I initially considered delivering the results as an ObservationCollection which helps group the various batches together using the SubmissionNo. However, I have gone with delivering a collection of LocatedSpecimens because that seems to be the main organisation of the database and I therefore assume the main end user use case. Both are valid and if I have time next year I will try to do an ObservationCollection mapping.

I haven't used any of the GA proposed GeochemicalMethod specializations. This is because they don't appear in my schema lists and I don't know where the schema is located. I think it does show however that further specialization of O&M is probably not required (it took some work before I finally found a way of encoding "Detection Limit"!).

I haven't attempted to include the additional non-geochemical regolith, geology, vegetation and meta data, concentrating instead on trying to get a geochemistry mapping. This could all be added if required.

Two areas of concern are: 1. The inability to specify from an om:Observation what the om:ObservationCollection is that it belongs to. I believe the association between the two should be bi-directional (Simon?) to allow identifying byReference the om:ObservationCollection. This would solve the problem that I have not been able to map SubmissionNo.

2. Almost every table in the database has a comment field. I am unsure which of these should be delivered. If all of them are required then there will need to be further work to sort out what they relate to. I have indicated which ones I think are most appropriate.

I will be away until early February so if you still want to deliver the geochemistry data in the AuScope portal then we can pick it up then. This will also give Gilly a chance to compare my mapping with the NVCL mapping, and Geoserver time to be able to handle some of the polymorphism and mappings.

Bruce Simons-- 30 Dec 2009


Bruce -

Regarding your encoding of the detection limit information: it is preferable for procedures to be registered and linked by-reference - this allows a single procedure to be associated with multiple observations, which is kind of the point of this separation of concerns. A once-off procedure is essentially what the observation class is supposed to model.

Observation/parameter is the preferred slot for event-specific parameters, so if the detection-limit really does vary on an observation-by-observation basis (unlikely?) with the rest of the procedure staying constant, then use this instead.

Regarding the direction of the member-set relationship - does an item know its bag? or does the bag know what it contains? The latter is more likely I think. But note that ObservationCollection has been removed from O&M v2, so probably best not to use it now. Else define it in your application schema. Either way, since you can't add an outbound association to OM_Observation itself, in order to instantiate such a relationship you'd have to subclass OM_Observation.

Simon Cox -- 5 Jan 2010


Hi Bruce and geochem gents,

I assume that while we await the release of GeoSciML v3 and O&M v2 schemas, we shall have to continue to write any geochemistry instances for existing data like your Yilgarn example using GeoSciML v2 and O&M v1?

Meanwhile, I have been modelling GSML v3 with the ISO O&M schemas (ie; O&M v2) which are a little different to the OGC O&M v1 schemas which you have used for you instance doc.

ObservedProperty, Specimen, and GeolUnit

I agree with you that to satisfy the O&M constraint which states that “observedProperty shall be a phenomenon associated with the type of the feature of interest”, we should invent an association to a ChemicalComposition property or class for GeologicUnits and Specimens. If we want to have a ChemicalComposition property for SF_Specimen, then we will need to subtype SF_Specimen because we don’t have editing rights for O&M classes. (And this is after we decided last year that we didn’t need to create our own geological subtype of SF_Specimen!!)

  • Summary_diagram_Geochemistry_OM_v22.jpg:
    Summary_diagram_Geochemistry_OM_v22.jpg

So I have resurrected the GeologicSpecimen subtype of SF_Specimen as a straw man again. And I have modelled a ChemicalComposition class linked to GeolUnit and GeologicSpecimen that could deliver a list of analyte concentrations within a single ChemicalComposition element. The attribute “AnalyteConcentration” delivers single analyte numbers (eg: 57% SiO2) , the attribute “AnalyteRatio” delivers analyte ratios (eg: U238/Pb206)

eg; an average chemical composition for a unit

<gsml:GeologicUnit>             
                   <gchem:geochemistry> 
                             <gchem:ChemicalComposition> 
                                      <gchem:analyteConcentration> 
                                                <swe:Quantity definition="urn:cgi:def:property:CGI:analyte:SiO2"> 
                   <!-- You could use gml:name attribute to identify the analyte here instead of, or as well as, the “definition” attribute  --> 
                                                          <swe:uom xlink:href="urn:ogc:def:uom:UCUM::%25"/> 
                                                          <swe:value>57.64</swe:value> 
                                                </swe:Quantity> 
                                      </gchem:analyteConcentration> 
                                      <gchem:analyteConcentration> 
                                                <swe:Quantity definition="urn:cgi:def:property:CGI:analyte:Al2O3"> 
                                                          <swe:uom xlink:href="urn:ogc:def:uom:UCUM::%25"/> 
                                                          <swe:value>16.39</swe:value> 
                                                </swe:Quantity> 
                                      </gchem:analyteConcentration> 
                                      <gchem:analyteConcentration> 
                                                <swe:Quantity definition="urn:cgi:def:property:CGI:analyte:Ni"> 
                                                          <swe:uom xlink:href="urn:ogc:def:uom:UCUM::ppm"/> 
                                                          <swe:value>25</swe:value> 
                                                </swe:Quantity> 
                                      </gchem:analyteConcentration> 
                             </gchem:ChemicalComposition> 
                   </gchem:geochemistry> 
          </gsml:GeologicUnit>

Alternatively, you could represent the results of an anlysis of a specimen thus:

<om:result>             
                   <gchem:geochemistry> 
                             <gchem:ChemicalComposition> 
                                      <gchem:analyteConcentration> 
                                                <swe:Quantity definition="urn:cgi:def:property:CGI:analyte:SiO2">   
                                                          <swe:uom xlink:href="urn:ogc:def:uom:UCUM::%25"/> 
                                                          <swe:value>57.64</swe:value> 
                                                </swe:Quantity> 
                                      </gchem:analyteConcentration> 
                             </gchem:ChemicalComposition> 
                   </gchem:geochemistry> 
          </om:result>   

ResultQuality and Process

I and our lab technicians agree with associating detection limits and errors with Observation-procedure-OM_Process, not with specimen-Observation-parameter. Analytical errors and detection limits vary per machine batch process per analyte, not per individual specimen/observation.

However, OM_Process in ISO O&M is a blank stub that requires us to extend it if we are to deliver any Process/resultQuality information using ISO O&M. So I have created straw man OM_Process subclasses for:
  1. Sampling Process (for use with SF_Specimen/samplingMethod),
  2. Specimen Preparation (for use with SF_Specimen/processingDetails), and
  3. AnalyticalMethod (for use with Observation/procedure), and
  4. I also put in a relation between the AnalyticalMethod with SpecimenPreparation. Just an idea, not sure if it’s really needed.
  5. I have put detection limits, quantitation limits, and analytical errors (all of which are are collected by our labs) in a class called AnalyticalLimits.

For example:

<gspec:GeologicSpecimen gml:id="CSIRONo1001813"> 
          <sa:materialClass>rock</sa:materialClass> 
          <om:samplingTime> 
                   <!-- SamplingTime is the date the sample was collected from the field, not analysis date.  The analysis date is Observation/resultTime.  --> 
                   <gml:TimeInstant> 
                             <gml:description>SamplingDate</gml:description> 
                             <gml:timePosition>11/09/2005</gml:timePosition> 
                   </gml:TimeInstant> 
          </om:samplingTime> 
          <sa:samplingMethod> 
                   <gspec:GeologicSamplingMethod> 
                             <gspec:method>diamond drilling</gspec:method> 
                   </gspec:GeologicSamplingMethod> 
          </sa:samplingMethod> 
          <sa:samplingLocation/>  <!-- eg; “a hill north of Kalgoorlie”, or easting/northing  --> 
          <sa:processingDetails> 
                   <gspec:GeologicSpecimenPreparation gml:id="XRF_Standard_Sample_Prep"> 
                             <gspec:preparationProcess>The specimen was crushed and cast using a 12:22 flux to form a glass bead</gspec:preparationProcess> 
                   </gspec:GeologicSpecimenPreparation> 
          </sa:processingDetails> 
          <sa:size> 
                   <gml:measure uom="urn:ogc:def:uom:UCUM::g">300</gml:measure> 
          </sa:size> 
          <sa:currentLocation/>   <!-- eg: GSWA rock store, Box #2347 --> 
          <sa:specimenType>HQ drill core</sa:specimenType> 
          <om:relatedObservation> 
                   <om:phenomenonTime> 
                             <gml:TimeInstant> 
                                      <gml:description>AnalysisDate</gml:description> 
                                      <gml:timePosition>11/11/2005</gml:timePosition> 
                             </gml:TimeInstant> 
                   </om:phenomenonTime> 
                   <om:resultTime>       <!-- will probably be the same as “phenomenonTime” mostly   --> 
                             <gml:TimeInstant> 
                                      <gml:description>ResultDate</gml:description> 
                                      <gml:timePosition>11/11/2005</gml:timePosition> 
                             </gml:TimeInstant> 
                   </om:resultTime> 
                   <om:procedure> 
                             <gchem:AnalyticalMethod gml:id="XRF_SiO2_SiemensBGT2000"> 
                                      <!-- This AnalyticalMethod information could probably all be done by reference, and used for observations on other specimens --> 
                                      <gchem:method>XRF</gchem:method> 
                                      <gchem:instrument>Siemens BGT 2000</gchem:instrument> 
                                      <gchem:resultQuality> 
                                                <gchem:AnalyticalLimits> 
                                                          <gchem:analyte codelist="urn:eg">SiO2</gchem:analyte> 
                                                          <gchem:analyticalError> 
                                                                   <swe:Quantity definition="urn:xxx:def:property:XXX::2SigmaAnalyticalError"> 
                                                                             <gml:name>2 Sigma Analytical Error</gml:name> 
                                                                             <swe:uom xlink:href="urn:ogc:def:uom:UCUM::%25"/> 
                                                                             <swe:value>0.05</swe:value> 
                                                                   </swe:Quantity> 
                                                          </gchem:analyticalError> 
                                                          <gchem:detectionLimit> 
                                                                   <swe:Quantity definition="urn:xxx:def:property:XXX::DetectionLimit"> 
                                                                             <swe:uom xlink:href="urn:ogc:def:uom:UCUM::%25"/> 
                                                                             <swe:value>0.1</swe:value> 
                                                                   </swe:Quantity> 
                                                          </gchem:detectionLimit> 
                                                          <gchem:quantitationLimit> 
                                                                   <swe:Quantity definition="urn:xxx:def:property:XXX::QuantitationLimit"> 
                                                                             <swe:uom xlink:href="urn:ogc:def:uom:UCUM::%25"/> 
                                                                             <swe:value>0.5</swe:value> 
                                                                   </swe:Quantity> 
                                                          </gchem:quantitationLimit> 
                                                </gchem:AnalyticalLimits> 
                                      </gchem:resultQuality> 
                             </gchem:AnalyticalMethod> 
                   </om:procedure>       
                   <om:observedProperty xlink:href="urn:cgi:propertyType:CGI:ChemicalComposition"/> 
                   <om:featureOfInterest xlink:href="#CSIRONo1001813"/> 
                   <om:result>             
                             <gchem:geochemistry> 
                                      <gchem:ChemicalComposition> 
                                                          <gchem:analyteConcentration> 
                                                                   <swe:Quantity definition="urn:cgi:def:property:CGI:analyte:SiO2"> 
                                                                             <swe:uom xlink:href="urn:ogc:def:uom:UCUM::%25"/> 
                                                                             <swe:value>57.64</swe:value> 
                                                                   </swe:Quantity> 
                                                          </gchem:analyteConcentration> 
                                                </gchem:ChemicalComposition> 
                                      </gchem:geochemistry> 
                             </om:result>             
          </om:relatedObservation>             
</gspec:GeologicSpecimen>

Comments please.

Ollie Raymond -- 25 Jan 2010


Hi Ollie,

Thanks for the response. I'm gradually working through your comments and recreating the instance document accordingly. I will respond as I see discussion points arising!

observedProperty

I still can't see the need for creating the Geochemistry:ChemicalComposition DataType and therefore the need for the GeologicSpecimen specialization. Using your swe:Quantity example rather than my gml:Measure captures all the required information, admittedly by specifying "urn:cgi:def:property:CGI:analyte:SiO2"without specifying that the result is an analyteConcentration.

<<fragment>> 
                       <sa:relatedObservation> 
                               <om:Observation gml:id="CSIRONo100181_SNu73858_0_SiO2"> 
                                       <gml:description>SiO2 analyte concentration</gml:description> 
                                       <gml:name>SiO2</gml:name> 
                                       <om:samplingTime> 
                                               <gml:TimeInstant> 
                                                       <gml:description>AnalysisDate</gml:description> 
                                                       <gml:timePosition>11/11/2005</gml:timePosition> 
                                               </gml:TimeInstant> 
                                       </om:samplingTime> 
                                       <om:procedure xlink:href="#Au_ARL1_ICP-MS"/> 
                                       <om:observedProperty xlink:href="urn:cgi:propertyType:CGI:ChemicalComposition"/> 
                                       <om:featureOfInterest xlink:href="#CSIRONo100011"/> 
                                       <om:result> 
                                               <gml:description>concentration of an analyte</gml:description> 
                                               <gml:name>analyteConcentration</gml:name> 
                                               <swe:Quantity definition="urn:cgi:def:property:CGI:analyte:SiO2"> 
                                                       <swe:uom xlink:href="urn:ogc:def:uom:UCUM::%25"/> 
                                                       <swe:value>48.7</swe:value> 
                                               </swe:Quantity> 
                                       </om:result> 
                               </om:Observation> 
                       </sa:relatedObservation>

I seem to recall in an early UML diagram Observation (or a subtype) had two properties:- "result" and "resultDefinition". Since resultDefinition is no longer, I gather the thinking is that information such as "analyteConcentration" should be put in om:procedure rather than om:result, which is where your example has it.

I still have to digest your detection limit comments - too much to think about and not enough brain power!

Bruce Simons -- 27 Jan 2010


“...I still can't see the need for creating the Geochemistry:ChemicalComposition DataType...”

3 reasons:

1. Unless Simon can correct me, I would assume that the observedProperty (xlink:href="urn:cgi:propertyType:CGI:ChemicalComposition") has to be a real property (ie; it exists in a schema somewhere), rather than our current phantom property which does not exist in any schema.

This is a problem with O&M that I believe is being redressed by lifting the restriction - otherwise every feature must have a property defined for every potential measurement that can be made on it. If it isn't redressed then yes we will need to have these properties specified somewhere. - Bruce Simons 27 Jan 2010

2. It allows a group of analyte concentrations (or ratios) to be delivered in one Observation/result element (eg; Cu, Pb, and Zn; or Pb, U, Th, and U238/Pb206) with one Procedure (eg; Wet_chem_assay; or SHRIMP_ion_probe), rather than delivering just one analyte per Observation/result with a Procedure for each analyte as your model does. The associated AnalyticalLimits class allows delivery of multiple analyte limits for one Procedure (eg; you could deliver all the limits for SiO2, Al2O3, MgO, TiO2 etc in one association to a single Procedure called “XRF_Major_Oxides”.)

According to the Yilgarn database, each analyte has a unique Method-Digest-Technique-Detection Limit combination. As Simon indicated the Procedures should be byReference so delivering the major oxides will still only deliver one procedure. - Bruce Simons 27 Jan 2010

3. The new ChemicalComposition class allows a group of analyte concentrations to be associated with a GeologicUnit (eg; an average whole-rock analysis for a unit). We currently have no other way of delivering that kind of data for a unit. I thought that GeologicUnit->ChemicalCompostion would be a useful Use Case.

This is a valid use case which is similar to the gsml:PhysicalDescription use case. Do we keep adding classes to capture all the physical properties GeologicUnits could potentially have? Assuming we do, is the geochemistry class the way to do it? If I have a K%, Th ppm or U ppm estimate for a GeologicUnit from spectrometer results, are they 'geochemistry' attributes or a separate class again ('radioelements'?)? Personally, I'd like to have a PhysicalDescription class which has one attribute consisting of a "propertyType:result" pair, ie soft type all physical properties. - Bruce Simons 27 Jan 2010

Ollie Raymond -- 27 Jan 2010


Hi all,

resultQuality and Process

I agree with Simon and Ollie re associating detection limits with a procedure and then referencing that procedure via OM_Process from the analyte Observation.

As Ollie notes, OM_Process is abstract and therefore requires specialization. He has suggested a Geochemistry:AnalyticalMethod class with properties "method" and "instrument". This seems highly generic. Is there a SensorML class we could use here instead?

Regarding AnalyticalMethod:method a single name is probably insufficient. The Yilgarn database has 'Method' (eg "ICP_MS"), 'Digest' (eg "Aqua"), 'Technique' (eg "ICP102") and 'Laboratory' (eg "Ultra Trace"), all of which could be "method" information. Again a reason I'd rather use a more complete SensorML based OM_Process if one is available.

Similarly I'd have thought SensorML would provide placeholders for detection limits. Is this not the case?

Bruce Simons -- 27 Jan 2010


Hi Bruce,

I agree that the Instrument and Method need to be fleshed out a lot more. I really only put placeholders in the diagram for discussion.

Here’s my reading of existing ISO data models...

The ISO 19130 model (SensorML) is very much geared towards imaging and remote sensors like satellites, cameras, videos, radars, etc. As far as I can tell, it is not designed to handle laboratory chemical analyses of physical samples (I’m happy to be proved wrong on this point).

Instrument

I have not been able to find any instrument-like class in ISO packages that is suitable for our purposes (eg, for XRF, ion probe, mass spec, ICPMS, etc). For example, there is SensorML ‘MI_Instrument’ in a package called ‘Acquisition Information - Imagery’ - not what we want. There is a ‘PS_Instrument’ which has more comprehensive instrument attributes, but I don’t want to use a class from a model called “ISO 19116 Positioning Services” which is clearly not designed for our domain.

The preliminary GA work created an AnalyticalInstrument class which captures a lot of instrument information. It was designed by the SHRIMP geochonologists specifically for an ion microprobe, but could be applied to any geochemical instrument with a bit of tweaking. What do you think?

  • AnalyticalInstrument.jpg:
    AnalyticalInstrument.jpg

Method

I have found no classes in SensorML or other ISO schemas that might handle the assay laboratory method information we want to deliver - eg, method name, digest, technique, lab name, etc. ISO19115 Metadata could handle some generic things like CI_ResponsibleParty (ie; laboratory name), but not for specific geochemical method attributes. I think we will still end up making extensions to existing models.

DetectionLimits, Errors

I couldn’t find anything in SensorML for dealing with analyte concentration limits/errors. But we could do away with the AnalyticalLimits class and use ISO 19115 Metadata “Data quality information::DQ_QuantitativeAttributeAccuracy” instead (see example below).

  • Process.jpg:
    Process.jpg
<gchem:AnalyticalMethod> 
    <gchem:resultQuality> 
          <gmd:DQ_QuantitativeAttributeAccuracy id="Copper_analytical_error"> 
                   <gmd:nameOfMeasure> 
                             <gco:CharacterString>Analytical Error - Copper</gco:CharacterString> 
                   </gmd:nameOfMeasure> 
                   <gmd:result> 
                             <gmd:DQ_QuantitativeResult>    <!-- This class is very similar to swe:Quantity, but with a useful optional “errorStatistic” attribute  --> 
                                       <gmd:valueUnit > 
                                                 <gml:UnitDefinition gml:id="ppm_Cu"> 
                                                          <gml:name>parts per million</gml:name> 
                                                          <gml:quantityType>Cu</gml:quantityType> 
                                                          <gml:catalogSymbol>ppm</gml:catalogSymbol> 
                                                 </gml:UnitDefinition> 
                                       </gmd:valueUnit> 
                                       <gmd:errorStatistic> 
                                                <gco:CharacterString>2 sigma</gco:CharacterString> 
                                       </gmd:errorStatistic> 
                                       <gmd:value> 
                                                <gco:Record> 
                                                          <gml:measure uom="ppm">0.5</gml:measure> 
                                                </gco:Record> 
                                       </gmd:value> 
                             </gmd:DQ_QuantitativeResult> 
                   </gmd:result> 
          </gmd:DQ_QuantitativeAttributeAccuracy> 
    </gchem:resultQuality> 
    <gchem:resultQuality>    
          <gmd:DQ_QuantitativeAttributeAccuracy id="Copper_detection_limit"> 
                   <gmd:nameOfMeasure> 
                             <gco:CharacterString>Detection Limit - Copper</gco:CharacterString> 
                   </gmd:nameOfMeasure> 
                   <gmd:result> 
                             <gmd:DQ_QuantitativeResult> 
                                      <gmd:valueUnit xlink:href="#ppm_Cu"/> 
                                      <gmd:value> 
                                                <gco:Record> 
                                                          <gml:measure uom="ppm">2</gml:measure> 
                                                </gco:Record> 
                                      </gmd:value> 
                             </gmd:DQ_QuantitativeResult> 
                   </gmd:result> 
          </gmd:DQ_QuantitativeAttributeAccuracy> 
    </gchem:resultQuality> 
</gchem:AnalyticalMethod>

Ollie Raymond -- 28 Jan 2010


Hi Ollie,

Thanks for your comments.

Instrument

OK so it looks like we have to create an "AnalyticalInstrument" class for our specific purposes. I believe this should be as generic as possible to not only handle geochemistry and geochronology but also other geoscience analytical methods. I would like to get the NVCL experts input on your proposal as they also store instrumentation information about the hyperspectral scanners that they wish to deliver via a WFS. Do you mind if I forward your proposal to them for comment?

Method

I understand your reluctance to use the ISO 19115-2 Metadata-Imagery packages. However, the patterns used in LE_Processing and MI_Instrument could be re-used for our methods.

  • algorithm.jpg:
    algorithm.jpg

I would expect the NVCL could re-use the LE_Algorithm pattern.

DetectionLimits, Errors

I like the idea of using the 19115 Metadata “Data quality information::DQ_QuantitativeAttributeAccuracy” for this, it looks like it handles everything we want. Can we use ISO 19115 in a WFs or do we need to use its XML implementation (ISO 19139) which doesn't cover the Data Quality aspects?

Namespace

I think we should avoid the Geochemistry namespace as being too restrictive. What about something more general like LaboratoryML, AnalyticalInstrumentML ...?

Bruce Simons -- -- 28 Jan 2010


Hi Bruce,

1. Re ".. Do you mind if I forward your proposal to them for comment?.." Please do.

2. Re Method... I am happy to mimic the patterns used in ISO 19115-2 Metadata-Imagery, but not to re-use the actual ISO classes. The packages and many of the ISO classes are specifically named and/or described for satellite imagery (eg; the notes for LE_Algorithm = 'Description: Details of the methodology by which geographic information was derived from the instrument readings'). So these classes are not really generic classes that can be re-used.

Another example is when I looked at using classes/attributes from SensorML to describe an image (eg, a photo taken by a geochronologist of zircon grains), but found descriptors like ?cloud cover percentage? and image condition codes like 'snow' (certainly nothing to accommodate ?cathodoluminescence microscope image?), which made me think 'Are SensorML and the ISO metadata packages describing all images, or just remotely sensed images?'.

3. Re 19115 vs 19139. I don?t know the relationship between 19115 and 19139. But the xml fragment I gave of DQ_QuantitativeAttributeAccuracy was valid using the ISO gmd and gco schemas http://www.isotc211.org/2005/gmd/) which appear to correspond in the main to the 19115 UML model, not the 19139 UML.

So it appears that the ISO 19115 classes are OK to use in a WFS. (Is that right Simon??)

4. Re namespace. I have no problems about making ?Geochemistry? more generic. How about calling the Application Schema and Namespace? LaboratoryAnalysis?, and the prefix ?lab?? (I thought about ?anal? but decided against it for some reason.)

Ollie Raymond -- 28 Jan 2010


2. In the MOLES project I did for NERC, we used the 19115-2 classes as part of a generic approach to scientific metadata. The whole thing is a mixture of 19115, 19115-2 and 19156 (i.e. O&M v2). Contact spiros.ventouras@stfc.ac.uk & bryan.lawrence@stfc.ac.uk to get access to their Trac and SVN.

3. 19139 is primarily an encoding rule, though it also specifies the namespaces for 19115. The model is 19115. The standard implementation of 19115 is described in 19139 and available from http://schemas.opengis.net/iso/19139/20070417/gmd/gmd.xsd

P.S. here's the summary model for MOLES 3. Spiros has made some small updates, but this shows how we used 19115-2 classes.

Simon Cox -- 28 Jan 2010

  • Summary_MOLES3.jpg:
    Summary_MOLES3.jpg


Hi Peter, (email forwarded to Peter.Warren@csiro.au)

Below ('above' in this record of emails) you will find extensive discussion between Ollie Raymond (GA) and myself on options for encoding geochemistry data.

We seem to be iterating toward:
  1. Method - using the SensorML patterns as a basis for establishing 'LaboratoyAnalysis' classes more appropriate for the kind of methods we deal with (ie non-remote sensed);
  2. Instrumentation - using the SensorML patterns as a basis for establishing 'LaboratoyAnalysis' classes more appropriate for describing the kind of instrument we deal with;
  3. Detection Limits - using DQ_Element (Data Quality Metadata) to capture detection limits and the like.

There is still some discussion happening (Simon Cox has indicated that something similar was done by NERC in the UK, but it looks to me like it is still all imagery instrumentation. I would appreciate your (and Jon's) thought's on what properties are required to capture the HyLogger instrumentation and method details.

Bruce Simons -- 29 Jan 2010


Hi Simon,

The MOLES 3 work still looks like it suffers from all the instrumentation/methods being platform (ie remote-sensed imagery) centric. Any thoughts on us using the same patterns, but with more appropriate properties for 'LaboratoryAnalysis' methods and instruments?

Bruce Simons -- 29 Jan 2010


Hi Bruce

"...The MOLES 3 work still looks like it suffers from all the instrumentation/methods being platform (ie remote-sensed imagery) centric. Any thoughts on us using the same patterns, but with more appropriate properties for 'LaboratoryAnalysis' methods and instruments? ..."

MOLES absolutely has to support laboratory analysis methods and instruments too. You're right that it's not obvious that it does as it stands, and as Simon suggested, we need to address that. There are certainly some issues when we start with such a remote sensing heritage, but Simon and I discussed that when we took the decision to go that way rather than start with yet another blank canvas ... and as you suggest, we extend very significantly away from the remote sensing origins.

We intend MOLES to be more than just a NERC activity, so you're (all) more than welcome to join the mailing list (see http://proj.badc.rl.ac.uk/moles) and get involved by providing use cases, and suggested extensions and/or changes. Now's certainly the right time. (I should note that we also don't intend MOLES to be everything, it has to work with domain specific schema like GeoSciML etc, rather than compete with them).

Bryan Lawrence -- 31 Jan 2010


Hi Bryan,

There are some tentative moves in this direction with BODC metadata and vocabulary development. If you look at the instrument classes I'm working with at the moment I've got sample collectors (e.g. water bottle - L051), sample processors (e.g. filter cascade - L052) and sample analysers (e.g. mass spectrometer - L054). These are included in our latest metadata schema as a simple workflow. Mapping this onto MOLES is very much part of my game plan.

Roy Lowry -- 1 Feb 2010


Hi GeoSciMLers,

Where are we up to with including geochemistry in Testbed4?

Do we want to persist with Ollies proposals,
  1. try to use 19115 for Detection Limits
  2. create classes for the Instrumentation and methodology
  3. create a specialization GeologicSpecimen to allow creation of

"ChemicalComposition" property (or some alternative way of dealing with the "observedProperty shall be a phenomenon associated with the type of the feature of interest" constraint)

Or wait, and work with the MOLES group, for a more generic approach?

Working with MOLES I believe is preferable, but may not enable us to deliver geochemistry as part of Testbed 4 (assuming that we are aiming for late 2010).

A compromise may be to deliver the data as per Ollie's 1 and 3 proposal, and try to use the MOLES:MO_Instrument for instrumentation and methods.

(Bryan - Is there a schema available).

I'm required to deliver geochemistry data this year as part of the AuScope project, so I'm keen to find a GeoSciML v3 solution that we can test

Bruce Simons -- 2 Feb 2010


Hi Bruce

I would defer to Simon's opinion on what is your most appropriate way forward, but note that we expect to evolve MOLES fairly rapidly after Easter. We have schema for the current version (3.2) on the moles website in the (public) source code repository (courtesy of Simon and FullMoon), and when we have a stable 3.3, we'll generate schema for that too ...

Bryan Lawrence -- 4 Feb 2010


I'm sitting with the (European) Remote Sensers in Frascati today (failed to intersect with Andrew Woolf, again).

Relevant to this discussion is that ISO 19115-2 is generally ignored even by the community that it is in theory connected to. The perception is that it
  1. is fundamentally limited by being linked to the bibliographically-oriented ISO 19115
  2. doesn't really satisfy any requirements, in particular no support for products.

Now I'm not sure that this means that 19115-2 is all bad, but I think it does say that a revision wouldn't be resisted too strongly.

Simon Cox -- 4 Feb 2010


Hi All

Here is my 2c

The debate is slowing again, which either means we are all busy or we arrived at a near optimal solution which currently has no better outcome. I am happy with near optimal, it should provide the platform for more debate smile

In the meantime I would love to be able to show off the geochemistry data set in this information model (whatever it looks like) and would like to do so in my project review stages (May).

What would the next steps be? What do we need to do it? Can it be done in the current time constraints?

Terry Rankine -- 8 Feb 2010


I have a MOLES meeting in London 4th March. Expect to raise this issue there.

Simon Cox -- 8 Feb 2010


Simon, I would appreciate you raising this at the MOLES meeting.

I am keen to deliver Terry's Yilgarn geochemistry as part of Testbed 4. As it is a testbed, if the method used is found wanting, so be it. However, I do need a direction to go, which based on the discussions so far is either:
  1. A variation on the initial mapping I carried out (wholly O&M);
  2. Use Ollie's proposed new classes and MD_Metadata links;
  3. Use the current MOLES classes

In terms of Terry's timelines (May 2010) I don't expect we would have a modified MOLES schema to work with by then. However, I'll wait for your report back from the MOLES meeting before progressing this.

Bruce -- 15 Feb 2010


Hi all,

I attach the latest LaboratoryAnalysis (aka Geochemistry) data model for comment.

1. It contains no links to MOLES. After some toing-and-froing with MOLES, I don’t think the existing MOLES schema is mature enough to be used by us in the timeframe that we need. However, the patterns used in LaboratoryAnalysis are similar to MOLES and I would be extremely happy to use a more mature version of MOLES at a later date. I would like to think that the MOLES team can use the LaboratoryAnalysis model as a guide for developing MOLES to be able to accommodate all kinds of analytical processes and instruments.

2. A core feature of LaboratoryAnalysis is the AnalyticalSession class. A lot of elements hang off AnalyticalSession, including AnalyticalInstrument. Steve may recognise this as very similar to the EarthTime model (see above).

3. One challenge is how to deliver a coherent set of analyte concentrations for a specimen that has been analysed by several methods (eg, XRF, ICPMS, AAS).... AFAICT we can deliver only one swe:DataRecord of results for each OM_Process. So to get a full geochem analysis for a specimen (eg, majors and traces), you might have several swe:DataRecords (one for each Observation-Process). You would then have to combine each of the Observation-result-DataRecords to get your complete geochem analysis using Observation-relatedObservation-Observation. Sounds messy, but I can’t see a way around it. Is this a case for the reinstatement of ObservationCollection into O&M?

4. Detection limits and analytical errors - how do we easily associate the analyte detection limit or analytical error defined in a session to the result for each analyte? Currently the result and the analytical error/detection limit have very different xpaths, and associating the two elements could be tricky. But if we use swe:Quantity to deliver both the Observation-Result and the Process-DetectionLimit then we could use a xlink:href pointer from Observation->result->DataRecord->Quantity->Quality->Quantity to the gml:id of the detection limit Quantity element (which is in Process->Acquisition->AnalyticalSession->ResultQualityDescription).

If we could use DQ_QuantitativeAttributeAccuracy for detection limits and still be able to xlink to it from the Observation-result-DataRecord-Quantity, that would be great, but I don’t know if we can do that.

Another option is to encode a single Observation and Process for each analyte. That would make the XML more bulky for multi-element analyses, but would make associating results to detection limits and errors much simpler.

Here is an attached instance document of how it might look: https://www.seegrid.csiro.au/twiki/pub/CGIModel/GeochemicalAnalysesDiscussion/LaboratoryAnalysis.xml

-- OliverRaymond - 24 March 2010
Topic attachments
I Attachment Action Size Date Who Comment
2009-09-10_CM-_RaGInG_SPOT_OM_and_GeoSciML2.jpgjpg 2009-09-10_CM-_RaGInG_SPOT_OM_and_GeoSciML2.jpg manage 771.5 K 23 Sep 2009 - 01:35 OliverRaymond GA preliminary geochem model - Sept 2009
AnalyticalInstrument.jpgjpg AnalyticalInstrument.jpg manage 42.1 K 16 Feb 2010 - 14:04 OliverRaymond  
EarthTime_Oct08.jpgjpg EarthTime_Oct08.jpg manage 118.0 K 23 Sep 2009 - 01:37 OliverRaymond EarthTime model Oct 2008
LaboratoryAnalysis.xmlxml LaboratoryAnalysis.xml manage 21.0 K 23 Mar 2010 - 09:18 OliverRaymond Proposed XML instance doc for a geochemistry analysis (March 2010)
Process.jpgjpg Process.jpg manage 158.3 K 16 Feb 2010 - 14:05 OliverRaymond  
Summary_MOLES3.jpgjpg Summary_MOLES3.jpg manage 603.0 K 16 Feb 2010 - 09:44 OliverRaymond  
Summary_diagram_Geochemistry_OM_v22.jpgjpg Summary_diagram_Geochemistry_OM_v22.jpg manage 483.5 K 16 Feb 2010 - 09:46 OliverRaymond  
Summary_diagram_LaboratoryAnalysis_OM_v2_24_March.jpgjpg Summary_diagram_LaboratoryAnalysis_OM_v2_24_March.jpg manage 360.8 K 24 Mar 2010 - 09:20 OliverRaymond updated proposed LaboratoryAnalysis model
algorithm.jpgjpg algorithm.jpg manage 199.3 K 16 Feb 2010 - 14:10 OliverRaymond  
Topic revision: r9 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).