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

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


Yes - I still strongly urge y'all to attempt a 'cull' of the soft-typed
values, 
and replace them with ScopedName (this _is_ ControlledConcept Steve!) or
Measure wherever possible. 
As Eric points out, you can actually write filters against those. 


--------------------------------------------------------
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: Thursday, 3 September 2009 11:21
To: auscope-geosciml at lists.arcs.org.au; steve.richard at azgs.az.gov;
auscope-geosciml at lists.arcs.org.au
Cc: Robin, Alexandre
Subject: [Auscope-geosciml] RE : CGI Value abomination [SEC=UNCLASSIFIED]

There still the WFS issue.
 
If one of the requirement is to be WFS (Filter) queriable, I don't think we
can go sweCommon. At least not with any softtyping solutions.  This said,
there are already many GeoSciML reasonnable queries that we can't do in
ogc:Filter.
Eric

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon Cox
Date: jeu. 2009-09-03 04:43
À: steve.richard at azgs.az.gov; auscope-geosciml at lists.arcs.org.au
Cc: 'Robin, Alexandre'
Objet : Re: [Auscope-geosciml] CGI Value abomination [SEC=UNCLASSIFIED]


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

_______________________________________________
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