"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"

Geochemistry Examples

Contents

Related pages
XmmlComponentIndex
XmlSchemaNotation \
GeochemistryMeasurement

Measurement view - procedure-oriented, "fully" normalised

fully normalised, with AssayProcedure, [Station,] GeochemSpecimen and GeochemMeasurement encoded as sibling objects - this is the most verbose form, but also the most expressive. 1-n associations between sampling-station and specimen, between specimens and measurements, including repeat measurements of a particular analyte are easily accommodated (see the WA examples for an illustration of the latter).

Note cross-references for values of subject, procedureUsed, etc, and also XPointers used for the value of gml:position - this points up to the value stored against the Specimen. As we have shown in ADX a table view for presentation can be relatively easily generated on-the-fly by XSLT transformation of fully normalised data similar to this.

ID's and cross-references

These examples package all the required information into a single document for convenience only, resulting in Feature Collections containing mixed feature-types.

Because all the objects are in a single document, the cross-references between the feature-instances may use relative URI's based on fragment identifiers (the #value syntax). In general the information is likely to be factored into several documents resulting from several service requests (as implied by the separators in the examples). In this case the integrity of the cross-references requires that either
  • all the relevant objects are known or generated by the same service, which assigns the handles and can thus ensure referential integrity
  • the value of the link contains the parameters required to allow a separate call to a(nother) service to reliably deliver the relevant objects.

The example XmmlSchemaRepository:trunk/Examples/geochem/WA_1_measurements_URNrefs.xml uses a tentative URN syntax to manage the latter requirement.

See LabelsAndHandles for more discussion regarding ID's, names and hrefs.

DavidHester has some suggestions for a logical, scalable ID generation rule for geochemistry measurements and specimens - see GeochemSpecimenAndMeasurementIDs.

Non-feature objects

AssayProcedure elements are used to collect the information describing a single assay procedure that may be used for many measurements. These objects are derived from gml:Definition, and thus are not "Features" so strictly cannot be direct members of a "Feature Collection". Hence, in the examples, a Dictionary of AssayProcedure elements is included in the "support" block. What kind of service can supply definitions? Well, in the absence of a Web Definition Service, or of viable implementations of WOS, in the short term we will probably need to "adapt" WFS to serve non-feature objects as well. In order to limit the set of general object types that we need to deal with, within XMML these supporting objects are mostly derived from gml:DefinitionType, and put in the gml:Definition substitution group.

Normalised pattern, but encoded inline

These examples show the same data as in the examples above, but with the hrefs resolved and the relevant objects encoded inline instead of remotely:

These patterns may be used if the data source cannot supply normalised data, so the results need to be expressed in a de-normalised form. But note that although the GeochemSpecimen now inlcudes all the results "inline" they are nested in child "features" that are exactly equivalent to the mixed feature-type examples above.

Feature view - sample-oriented

show results inline within the GeochemSample feature, each sample having several analyte results, each analyte shown separately as a analyteComponentResult property. This is a compromise between compactness and expressiveness while bundling all the results with a sample.

Analyte values are shown as simpleContent of elements using the standard GML "measure" pattern, with a mandatory XML attribute uom giving the scale. This pattern ensures that "normal" results, which should be the majority, are encoded in the normal, compact way. However, all additional information and variations from "normal" use XML attributes in various ways:
  • metadata is used to carry a link to additional information concerning this analyte value
  • metadataRole indicates the type of the metadata
    • observationEvent - i.e. the metadata attribute carries a link to the related Measurement View - see above
    • observationProcedure - i.e. the metadata attribute carries a link to the related Procedure description - see ProceduresAndInstruments
    • observationResponsibleParty - i.e. the metadata attribute carries a link to the related operator or laboratory - see BaseComponents#PartyPropertyType_actor
  • xsi:nil with a value of "true" is used to indicate that no value is available
  • nilReason may be used to record additional information for missing values; this may be one of the standard GML reasons (missing, inapplicable, withheld, unknown), or text prepended by other:, or may be a URI link to a more detailed explanation.

Note: Quantities representing ratios (percent, ppm, ppb etc) are "pure numbers", and should be encoded in unscaled form for transport, in scientific notation if necessary. This requires that the conversion from ppm, ppb etc is done on the server-side during, or preferably before, conversion to XML. However, the storage "units" might still be useful "metadata" even when the values are reporting as pure numbers, so this is recorded as the value of an originalUom attribute when available.

Coverage view - analysis-oriented, spatial variation property-by-property

transforms the results into the "coverage" (functional-map) view - the locations of the specimens are given in a posList, then the values for each property are given as a set of measureList's. The "RecordList" option could also be used for the range, in which case the same "reference system" (tuple structure description) would be used as described above.

As noted in InformationViews, this form is essentially "data prepared for analysis" - for example, patterns are generally visible when values of a single property are seen side-by-side.

 
Topic revision: r3 - 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).