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

Stephen M Richard steve.richard at azgs.az.gov
Thu Sep 3 19:48:27 EDT 2009


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20090903/402d2ca2/attachment.htm>


More information about the GeoSciML mailing list