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

Simon Cox simon.cox at jrc.ec.europa.eu
Wed Sep 2 05:54:34 EDT 2009


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

----------------------------------------------------------------------------
--------------------
Ollie Raymond
National Advice,  Maps and Standards Project Geoscience Australia

Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039
Ph: (02) 62499575 | Fax: (02) 62499992 | Email: Oliver.Raymond at ga.gov.au
Web:
http://www.ga.gov.au/minerals/research/national/nat_maps/nat_geol_maps.jsp
Google Map

-- This message was created with 100% recycled electrons --



-----Original Message-----
From: Rob.Atkinson at csiro.au [mailto:Rob.Atkinson at csiro.au]
Sent: Wednesday, 2 September 2009 2:28 PM
To: auscope-geosciml at lists.arcs.org.au
Cc: auscope-geosciml-bounces at lists.arcs.org.au; Raymond Oliver
Subject: RE: [Auscope-geosciml] CGI Value abomination

Next week I'll be visiting Simon, and will be happy to put this on the
agenda to explore and suggest a straw man solution.

If this is not suitable timing, I'll try to mock somethign up in the
meantime.

but basically - you leave the CGI_term and TermValue classes, but you
redefine them as specialisations of the base class we decide to use - I need
to understand where ISO19146 is at, but it seems to be exactly what we would
need.

CGI_term may have some additional semantics or properties, but this should
be able to be handled.

Rob

________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au
[auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of
Bruce.Simons at dpi.vic.gov.au [Bruce.Simons at dpi.vic.gov.au]
Sent: Wednesday, 2 September 2009 2:21 PM
To: auscope-geosciml at lists.arcs.org.au
Cc: auscope-geosciml at lists.arcs.org.au;
auscope-geosciml-bounces at lists.arcs.org.au; Oliver.Raymond at ga.gov.au
Subject: Re: [Auscope-geosciml] CGI Value abomination


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.






_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

--
This message (and any attachments) is for the recipient only. NERC is
subject to the Freedom of Information Act 2000 and the contents of this
email and any reply you make may be disclosed by NERC unless it is exempt
from release under the Act. Any material supplied to NERC may be stored in
an electronic records management system.

_______________________________________________
Auscope-geosciml mailing list
Auscope-geosciml at lists.arcs.org.au
http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml




More information about the GeoSciML mailing list