[Auscope-geosciml] CGI Value abomination [SEC=UNCLASSIFIED]

Stephen M Richard steve.richard at azgs.az.gov
Wed Sep 2 12:14:47 EDT 2009

Simon--Interoperability is defined by some community of practice. Sure, 
some group could agree to some free text format for data interchange, 
but then they'd dispense with xml and OGC services entirely and pass 
around tab-delimited text files.  We've been there, and know how well or 
poorly that works.

What is the problem with leaving the xml schema quite general, allowing 
for different value quantification schemes, with the understanding that 
communities wishing to share data using GeoSciML services will have to 
develop an application profile restricting some of the possibilities? 
The benefit of the model is in establishing patterns for how this is 
done, so that each solution to the same problem is not different.

To me the important question for Quebec is how much we can do using SWE, 
since the value quantification issue is certainly not only a geoscience 
problem! Maybe replace CGI_Value with some element (swe:DataArray?) or 
elements from SWE. We need to analyze the places CGI_Value is used in 
GeoSciML (see list below), and figure out if there is more than one 
pattern, and decide if we need to change it.


> CGI_Value is used for:
> Bedding thickness
> Event age
> part proportion (GUPart, composition, rock constituent part)
> several geophyscial properties (magnetic susceptibility, permeability, 
> porosity, CGI_PhysicalDescription)
> mapped feature position accuracy
> trend, plunge, azimuth and dip on orientation values
> particle geometry description properties (grain size, sorting, shape, 
> and aspect ratio)

Simon Cox wrote:
> In that case you can make everything that is not an 'interoperable' field
> just free-text. 
> This would still say that CGI-Value could be dispensed with.  
> --------------------------------------------------------
> Simon Cox
> European Commission, Joint Research Centre, 
> Institute for Environment and Sustainability, 
> Spatial Data Infrastructures Unit, TP 262 
> Via E. Fermi, 2749, I-21027 Ispra (VA), Italy 
> Tel: +39 0332 78 3652
> Fax: +39 0332 78 6325
> mailto:simon.cox at jrc.ec.europa.eu 
> http://ies.jrc.ec.europa.eu/simon-cox 
> SDI Unit: http://sdi.jrc.ec.europa.eu/ 
> IES Institute: http://ies.jrc.ec.europa.eu/
> JRC: http://www.jrc.ec.europa.eu/
> --------------------------------------------------------
> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Laxton,
> John L
> Sent: Wednesday, 2 September 2009 11:39
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [Auscope-geosciml] CGI Value abomination [SEC=UNCLASSIFIED]
> The snag with limiting users to the number of formats they can use is that
> the chosen format may not match the user's database. We recently hit this
> with unitThickness defined as CGI_Numeric. Fair enough you might think but
> in our database unit thickness is a string with comments like 'c23m in
> Grantham area'. The unfortunate reality is that in lots of cases different
> data providers hold the same property in different formats. We could remodel
> them as distinct properties for different formats (Ollie's option (b)) but
> this is only going to be worthwhile where we wish to query against the
> property. In most cases all we wish to do is deliver a property value and
> I'm not convinced it matters if the way BGS delivers something like
> ParticleGeometryDescription.sorting is different from the way AZGS does - we
> need to be realistic about the level of interoperability needed. Particular
> services can always specify more restrictive requirements if needed as
> OneGeology-Europe is doing.
> John
> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au
> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of
> Oliver.Raymond at ga.gov.au
> Sent: 02 September 2009 05:49
> To: Rob.Atkinson at csiro.au; auscope-geosciml at lists.arcs.org.au
> Subject: Re: [Auscope-geosciml] CGI Value abomination [SEC=UNCLASSIFIED]
> I agree with Simon's sentiments.  But Rob's comments have me confused.  I
> can't see how making CGI_Value a specialisation of another class is going to
> make the model more interoperable.  It still leaves users able to deliver
> some attribute values as either term values, number values or ranges.
> The aim here is to:
> a) limit users in the number of formats they can use to deliver attribute
> values, and
> b) redefine some model elements (eg: Age) so that they explicitly state, for
> example, "this attribute is for a numerical Age only" or "this attribute is
> for a term Age only", rather than the existing "this attribute can be a
> numeric Age, or a term Age, or a range of numeric and term Ages".
> Cheers,
> Ollie

Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Office: (520) 209-4127
Reception: (520) 770-3500 
FAX: (520) 770-3505

email: steve.richard at azgs.az.gov

More information about the GeoSciML mailing list