[Auscope-geosciml] CGI_Value

Tue Sep 1 12:44:46 EDT 2009

TermValue is actually used more than CGI_Value.

CGI_Value is only 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)

In the real world, all of these properties may be specified with 
categorical terms or some numeric parameter, and either option may show 
up in quality controlled archival data. Its not a question of 
laziness--its a real problem for what interoperability means. Forcing 
use of categories loses the (perhaps imaginary...) precision of numeric 
values, causing information loss. Forcing use of numeric values makes 
categorical data look more quantitative than it really is. Allowing 
either option creates headaches for the computer processing. Guess which 
option the geologists like... 

I think we were actually pretty careful to use the narrower value 
subtypes where it makes sense for geology.  

I have also suggested the option of keeping the generic value 
representation structure in the model/xml schema, and leaving it to 
application schema utilizing the model to proscribe more restrictive 
rules for representing quantities. The decision should be based on 
what's easier--interoperability using different schema for closely 
related content, or interoperability based on application profiles that 
restrict the use of a single schema?  Based on what I'm seeing in the 
ISO19139 applications, there seems to be plenty of attempts at the 
second option.

steve

Simon Cox wrote:
> Ollie, others:
>  
> I have been grumbling about this for a while, and hope that it can be 
> addressed in the upcoming meeting in Quebec.
>  
>  
> Way too many of the class attributes in GeoSciML use CGI_Value and its 
> variants.
>  
> I am fully aware of the history of when CGI_Value it was created 
> (Ottawa, 2005) and its value (it allowed us to move forward on the 
> bigger issues).
> It also allowed a lazy UML design process, where for most atttributes 
> the type was set following a logic of just 'we can't really think 
> about this now but it'll be some kind of word/number'.
>  
> Now I think it is time to set it aside and move on.
>  
> My fundamental objections to the almost ubiquitous use of CGI_Value are
> (i) it is hard to implement - it relies on XML Schema substitution groups
> (ii) it is not compatible with any other domain schema
> (iii) it allows data providers to be 'lazy' and create instances that 
> are not interoperable on arrival
> (iv) it forces decisions required for data-fusion over to the client - 
> this is fundamentally what a standard encoding is supposed to avoid!
> (v) it privileges a marginal GeoSciML use-case (transmission of field 
> data) at the expense of the dominant use-case (exchange of 
> quality-controlled archival data). 
>  
> Most of the time, the client will refer to 'standard definitions' 
> provided in the GeoSciML concept schemes to translate the values 
> provided into standard forms anyway, so why not get the provider to do 
> that rather than the client
>  
> It is the job of the GeoSciML design task group to actually make 
> some choices, fix the type of the basic class attributes, and then 
> require that service providers conform - make them make the choice 
> about the 'best' value for an attribute, don't shirk the job and push 
> it back to the client.
>  
> Almost all CGI_Value should be replaced by
> (a) ScopedName
> (b) Measure
> with just a few being
> (c) Range (new type)
>  
> Simon
>  
>  
>
> --------------------------------------------------------
> *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/
>
> --------------------------------------------------------
>
>  
> ------------------------------------------------------------------------
>
> _______________________________________________
> Auscope-geosciml mailing list
> Auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>   

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

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

email: steve.richard at azgs.az.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20090901/2a304ad1/attachment.htm>