[Auscope-geosciml] RE : gml names, codespaces, and OGC filters

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Thu Sep 3 22:54:45 EDT 2009


arg, sorry,  ignore this.  I meant that using sequence is a terrible hack.
 
Did I mention that I'm still challenged by english ?
 
 

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Boisvert, Eric
Date: jeu. 2009-09-03 21:38
À: steve.richard at azgs.az.gov; auscope-geosciml at lists.arcs.org.au
Objet : RE : [Auscope-geosciml] gml names, codespaces, and OGC filters


>Another alternative to requiring names in a certain order would be some kind of 'common queryable' defined in the application profile
 
no. this is a  terrible hack. Sorry I strongly oppose it.  

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Stephen M Richard
Date: jeu. 2009-09-03 19:48
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] gml names, codespaces, and OGC filters


Only if you are sure that the stratName comes first, and the map_symbol comes second, in which case the filter would look for gml:name[1] and gml:name[2] respectively.

I like using the gml:name with the codespaces to indicate various name roles. The best solution would be for wfs to allow attribute criteria on xpath's for elements. Another alternative to requiring names in a certain order would be some kind of 'common queryable' defined in the application profile; this would require use of some preprocessing of requests (e.g. a Cocoon pipe) using that profile to map into WFS compliant requests against the internal data schema for the implementation. Something we should figure out in Quebec.

steve

Oliver.Raymond at ga.gov.au wrote: 

	
	 
	So... as I understand it, I can't write a WFS filter to specifically query, for instance, Map_symbol or GeologicalUnitName in the instances below....
	 
	<gsml:GeologicUnit gml:id="GA_GeologicUnit_Stratno_134">
	<gml:name codeSpace="urn:cgi:classifierScheme:GA:StratigraphicLexicon:Stratname">Adelong Norite</gml:name> 
	<gml:name codeSpace="urn:cgi:classifierScheme:GA:StratigraphicLexicon:Map_symbol">Sgad</gml:name> 
	 
	<gsml:GeologicUnit gml:id="gu.26931319">
	<gml:name codeSpace="urn:cgi:classifierScheme:GSV:GeologicalUnitName">Bacchus Marsh Formation</gml:name> 
	<gml:name codeSpace="urn:cgi:classifierScheme:GSV:GeologicalUnitCode">Pxb</gml:name> 
	 
	Does the community see a need for a more GeoSciML-specific encoding of the geological unit name and map_symbol/unit_code/map_code, as opposed to the current use of the generic gml:name for both of these descriptors?  
	 
	A suggestion might be that gml:name be reserved strictly for the name of the unit (eg: Adelong Norite, Bacchus Marsh Formation), and we create a specific GeoSciML placeholder for map_symbol/unit_code/map_code?
	 
	Any thoughts?
	
	 
	------------------------------------------------------------------------------------------------
	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 <http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1>  
	 
	-- This message was created with 100% recycled electrons --
	 
	 
	 
	-----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 7:51 PM
	To: auscope-geosciml at lists.arcs.org.au; auscope-geosciml at lists.arcs.org.au; steve.richard at azgs.az.gov
	Cc: Robin, Alexandre
	Subject: [Auscope-geosciml] RE : RE : CGI Value abomination [SEC=UNCLASSIFIED]
	 
	Actually, you can't, or at least not to the point that codeSpace is of any use.  Filter sees the world in denormalised form.
	 
	consider this instance
	 
	<Feature>
	  <gml:name codeSpace="urn:1">concept_a</gml:name>
	  <gml:name codeSpace="urn:2">concept_b</gml:name>
	</Feature>
	 
	We want to select concept_a of codeSpace urn:2 (this instance should not match)
	 
	<ogc:And>
	   <ogc:PropertyIsEqualTo>
	     <ogc:PropertyName>gml:name</ogc:PropertyName>
	     <ogc:Literal>concept_a</ogc:Literal>
	   </ogc:PropertyIsEqualTo>
	   <ogc:PropertyIsEqualTo>
	     <ogc:PropertyName>gml:name/@codeSpace</ogc:PropertyName>
	     <ogc:Literal>urn:2</ogc:Literal>
	   </ogc:PropertyIsEqualTo>
	</ogc:And>
	 
	will match the instance
	 
	This problem has been reported some times ago.
	 
	This means that we can't really target specific codeSpace when we query a term, codeSpace are useless in filter.
	I know it is unlikely that many codeSpace for the same property are to be present in the same feature (gml:name is the only one I can think of), but just to point out that codeSpace can't be use to tell term apart in WFS/Filter.  You might as well ignore codeSpace filtering altogether. and hope that the term is unique.
	 
	I don't think it's a show stopper, it will return false positive in the worst case scenario.
	 
	Eric
	 
	 
	 
	 
	 
	________________________________
	 
	De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon Cox
	Date: jeu. 2009-09-03 05:31
	À: auscope-geosciml at lists.arcs.org.au; steve.richard at azgs.az.gov
	Cc: 'Robin, Alexandre'
	Objet : Re: [Auscope-geosciml]RE : CGI Value abomination [SEC=UNCLASSIFIED]
	 
	 
	 
	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
	 
	_______________________________________________
	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



More information about the GeoSciML mailing list