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

Simon Cox simon.cox at jrc.ec.europa.eu
Thu Sep 3 04:43:02 EDT 2009


Steve, Eric, John - 
 
I think you have a strong understanding of the requirements. 
Can I suggest you engage with Alex Robin directly. 
I'm sure he would be very pleased to assist, if it led to the adoption of
sweCommon in GeoSciML. 
Right Alex?
 
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> mailto:simon.cox at jrc.ec.europa.eu 
 <http://ies.jrc.ec.europa.eu/simon-cox>
http://ies.jrc.ec.europa.eu/simon-cox 

SDI Unit:  <http://sdi.jrc.ec.europa.eu/> http://sdi.jrc.ec.europa.eu/ 
IES Institute:  <http://ies.jrc.ec.europa.eu/> http://ies.jrc.ec.europa.eu/ 
JRC:  <http://www.jrc.ec.europa.eu/> http://www.jrc.ec.europa.eu/

--------------------------------------------------------

 


  _____  

From: auscope-geosciml-bounces at lists.arcs.org.au
[mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Stephen M
Richard
Sent: Wednesday, 2 September 2009 21:10
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] CGI Value abomination [SEC=UNCLASSIFIED]


The swe abstract data components all have a Quality property, which is a
union that includes a categoryQuality and textQuality. Can the kind of
qualifiers we're using (always, common, never, sometimes, rare, equalTo,
greaterThan, lessThan, approximate, quadratic mean, ...mode, median) be
accounted for using categoryQuality? CategoryQuality appears in the sensorML
v.1.0 uml in HollowWorld, but a search of the pdf for SensorML (OGC 07-000)
gets no hits on categoryQuality, so there's not any discussion of the
intention of the quality category. 

can swe:singleConstraint account for greaterThan, lessThan type bounding
value declarations?
the quadratic mean, harmonic mean, geometric mean, arithmetic mean, mode,
median have to do with the observation procedure, but how does swe attach
those to data?  Using abstractDataComponent.definition URI?
always, common, sometimes seem like possible quality categories. 
'Never' is only necessary for defining descriptions where the presence of
some property precludes membership in a category -- I don't think it would
appear in any kind of occurrence description. This kind of information
should be encoded with OWL or something like that anyway, so maybe we can
deprecate it. 

So maybe don't need to change swe?

BUT...
SWE does not appear to have a CategoryRange that would account for
CGI_TermRange.
We still have the case brought up by Bruce or Ollie of geophysical data for
which there is a value range and a typical or preferred value

Maybe these could be accounted for with some elements derived from
swe:dataArray?

steve


Simon Cox wrote: 

But if it is a common requirement, there should be a common slot for it,

rather than making it part of the tuple definition. 

The latter is pretty much back to free-text. 





--------------------------------------------------------

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 Boisvert,

Eric

Sent: Wednesday, 2 September 2009 19:22

To: auscope-geosciml at lists.arcs.org.au

Subject: Re: [Auscope-geosciml] CGI Value abomination [SEC=UNCLASSIFIED]



Can't the qualifier be modelled as a part of the complex value 



Eg:



<gsml:result>123 15 23.5 APPROX</gsml:result>



Just a thought





-----Message d'origine-----

De : auscope-geosciml-bounces at lists.arcs.org.au

[mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Simon Cox

Envoyé : 2 septembre 2009 12:26 À : auscope-geosciml at lists.arcs.org.au

Objet : Re: [Auscope-geosciml] CGI Value abomination [SEC=UNCLASSIFIED]



I was responding to John's mail, where he appeared to be saying 'some fields

will never be interoperable' (because of institutional reasons). If we

really think they aren't (and he may have a point here), then there is zero

benefit and only cost in forcing a data provider to coerce their

non-ineroperable data into complex structures. 



Eric brought up SWE Common as a (more broadly accepted) alternative, though

he pointed out that in practice SWE Common is as permissive as CGI_Value

(but probably has more code to support it - though I think it is only

maintained by one person (Alex Robin) who does not keep his documentation

up-to-date). 



If there is interest in looking at SWE Common as a replacement (I agree that

it probably has more momentum, and Alex is very diligent in publicizing it),

but are concerned about the absence of _qualifiers_ (or anything else in

fact) then can I suggest that this requirement is URGENTLY brought to the

SWE Common v2.0 revision working group in OGC - they are actively working on

v2.0, and my guess is it will be wrapped up in a matter of months. 





--------------------------------------------------------

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 Stephen M

Richard

Sent: Wednesday, 2 September 2009 18:15

To: auscope-geosciml at lists.arcs.org.au

Subject: Re: [Auscope-geosciml] CGI Value abomination [SEC=UNCLASSIFIED]



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.



steve



  

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



  

    

...clipped...



--

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



_______________________________________________

Auscope-geosciml mailing list

Auscope-geosciml at lists.arcs.org.au

http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml



_______________________________________________

Auscope-geosciml mailing list

Auscope-geosciml at lists.arcs.org.au

http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

_______________________________________________

Auscope-geosciml mailing list

Auscope-geosciml at lists.arcs.org.au

http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml



_______________________________________________

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/20090903/0bfeb66f/attachment.htm>


More information about the GeoSciML mailing list