[Auscope-geosciml] CGI Value abomination

Wed Sep 2 00:21:26 EDT 2009

I like Rob's suggestion - at least the bit I understand - "This way no 
client models actually need to change. The implementation of CGI_Value 
using the old model is now an implementation choice, that can be 
deprecated. "

What does the rest mean? ie how do we actually do it?

Bruce

GeoScience Victoria
EARTH RESOURCES DIVISION
Department of Primary Industries
Melbourne, Victoria
AUSTRALIA
Ph: +61-3-9658 4502
Fax: +61-3-9658 4555 
Mobile: +61 429 177155

<Rob.Atkinson at csiro.au> 
Sent by: auscope-geosciml-bounces at lists.arcs.org.au
02/09/2009 08:22 AM
Please respond to
auscope-geosciml at lists.arcs.org.au

To
<auscope-geosciml at lists.arcs.org.au>, <Oliver.Raymond at ga.gov.au>
cc

Subject
Re: [Auscope-geosciml] CGI Value abomination

would it be possible to recast CGI_Value as a facade to an implementation 
as a specialisation of ISO19146, and have a canonical implementation of 
ISO19146 using a pre-defined set of service interfaces (SKOS maybe + 
something with more ontological power?)

This way no client models actually need to change. The implementation of 
CGI_Value using the old model is now an implementation choice, that can be 
deprecated. New systems (with suitable deployment profiles) could demand 
the canonical implementation.

Rob Atkinson
Team Leader, Interoperable Systems
CSIRO Land & Water
Ph (mobile) +61 419 202 973

From: auscope-geosciml-bounces at lists.arcs.org.au 
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon Cox
Sent: Tuesday, 1 September 2009 5:10 PM
To: Oliver.Raymond at ga.gov.au
Cc: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] CGI Value abomination

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

Notice:
This email and any attachments may contain information that is personal, 
confidential, legally privileged and/or copyright.No part of it should be reproduced, 
adapted or communicated without the prior written consent of the copyright owner. 

It is the responsibility of the recipient to check for and remove viruses.
If you have received this email in error, please notify the sender by return email, delete 
it from your system and destroy any copies. You are not authorised to use, communicate or rely on the information 
contained in this email.

Please consider the environment before printing this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20090902/203df1d2/attachment.htm>