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

Example Geochemistry Data (PirSA)

SA requirements for publication through the MCA/AusIndustry/SEEgrid testbed.

Back to MCAGeochemistryExamples

Information model

Attached .xls contains two worksheets with extracts from existing views of parts of rock sample geochem module of SA_GEODATA. "sample headers" contains standard header type information for a few selected samples. "traces" contains corresponding trace element analysis results in denormalised format. The source data tables are fully normalised, but we have found that most users prefer presentation in the denormalised "wide table" format.

Limitations to views available through Public (web) Interface

Note on implementation: The web service login will not have access to the base tables, only to selected view(s). This is for reasons of security and performance. We will configure the view(s) to suit the model to be agreed upon.

-- GregoryJenkins - 21 May 2004

The key to the WFS approach is precisely that it is not a general purpose database query, but is limited to the feature-types advertised in the Capabilities document. The structure of these feature types is defined in the community schema, and would normally be a subset of the information available at source.

WFS can be thought of as a publishing service. Limited data-products are available, corresponding to the named feature types. It is precisely the job of the WFS software to generate selected view(s) (formatted in XMML/GML). The WFS software thus needs to understand the (private) source schema and the (public) schema for the feature types, and perform the necessary conversions of both queries and reports.

Your comment above could be interpreted as implying that a two-stage conversion is envisaged

base tables → selected views → XMML encoded features

where the WFS is only involved in the second arrow. Is this what you mean?

The WFS theory is that it shoudl be possible to generate the XMML regardless of source, so the first conversion may not be necessary, though it may be desirable for performance reasons. As far as the WFS software is concerned, all the links in the chain prior to the last step are opaque. What is needed in order to configure the WFS software is what its input and output are.

This leads onto the key question: do the XLS files reflect the structure of the source tables, or are they "reports"? We really need to know how the data source will look to the WFS software, in order to know what processing is needed to convert this into XMML.

-- SimonCox - 30 Jun 2004

As stated above, specific database views will be created for this project. This is due to corporate policy requirements related to security and performance. The views are to be built according to requirements to be agreed between the project participants. It is the content of these views which will be published to the capabilities document and exposed to WFS software via XMML. For the S.A. component of the project, it is intended that the conversion to XMML will take place at database/server end, so that WFS (or other) client software will only see a "black box" which receives and delivers XMML.

The .xls file examples are reports produced from database views. They contain the data fields which we consider appropriate for publication, and which have been of interest to most clients.

-- GregoryJenkins - 13 Jul 2004

In simplified textual form, the denormalised schema to be used is:

Site (one->many) Sample (one->many) Analysis (one->many) Analysis Result

Site contains coordinate information, Sample contains sample header information, Analysis specifies laboratory, batch etc., and Analysis Result specifies analyte, value, method. There are related authority tables for some of the fields.

In view of the time constraint and the fact that this is a demonstrator only, we have decided to expose the minimum of useful information. Even this will lead to some quite complex processing. Further information can be exposed after resolution of issues raised during demonstrator implementation. It is proposed to expose:

Point coordinates; System sample number; Sample type; Collector's name; Collector's sample identifier; Collection date; Analytical laboratory; Analyte; Analyte value; Value range; Value unit; Analysis method.

This is a considerable reduction on the fields in the example spreadsheet. Sample preparation has been specified by other agencies. In SA's case, the equivalent fields are poorly populated at present, and will not be exposed.

GregoryJenkins - 29 Jul 2004

In this description, "Analysis" appears to mean "Analysis suite" or "Analysis event at a single lab and using a single method that results in estimates of the values of several analytes". Is that correct?

Thanks for clarification of sample details.

-- SimonCox - 30 Jul 2004

In our system, a single sample analysis record refers to a distinct generic analysis type (geochemistry, geochronology, petrology...) carried out by a single laboratory on a single sample for one or more analytes using one or more analysis methods. There may be multiple analysis methods and results for a particular analyte tied to a sample analysis record, e.g. repeat Au assays.

-- GregoryJenkins - 02 Aug 2004
Topic attachments
I Attachment Action Size Date Who Comment
SA_sample_geochem.xlsxls SA_sample_geochem.xls manage 30.5 K 21 May 2004 - 10:14 GregoryJenkins selected sample headers and analysis results
Topic revision: r14 - 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).