[GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Sun Jun 30 10:35:35 EDT 2013

This pretty much solves the problem.    Do we still need to a CR then ? (I was looking into this)

Minor point though..

The way it's implemented, a GSML_QuantityRange can be either a swe:value and/or a lowerValue and/or a upperValue so this

<swe:value>90 100</sweValue>
is valid.

(I assume that missing upperValue or lowerValue means that the range is open)

 proably need a bit a schematron to constrain here ?.  Since the whole point of this class is to expose FES friendly properties (sigh) I suppose the rule is that either one or both of lowerValue and upperValue should be present.

Do we let swe:value serialization as valid representation ?  For instance, can someone build a FES filter over lowerValue/upperValue but receive a response only using swe:value ? This is the problem when we have multiple representations..  If lowerValue and upperValue is just a query representation, we can state that the serialisation uses swe:value.

My 2 cents

De : geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatial.org [geosciml-bounces+eric.boisvert=rncan-nrcan.gc.ca at lists.opengeospatial.org] de la part de Laxton, John L. [jll at bgs.ac.uk]
Date d'envoi : 26 juin 2013 04:15
À : Public: A mailing list for GeoSciML
Objet : Re: [GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

Hi Ollie,

That looks good to me and is what we discussed/agreed in St Petersburg. Putting GSML_QuantityRange in the Utilities package would seem the most logical as you say (it’s where the old CGI_Value etc were).


From: geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org [mailto:geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org] On Behalf Of Oliver.Raymond at ga.gov.au
Sent: 26 June 2013 03:48
To: geosciml at lists.opengeospatial.org
Subject: [GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

Hi all,

If the SWECommon SWG cannot publish a quick change to swe:QuantityRange as SWECommon v2.1 (unlikely?), then I propose the following changes for GeoSciML version 3.2:

1.       Create a new class called GSML_QuantityRange

a.       a child of swe:QuantityRange

b.      contains two attributes – lowerValue and upperValue, both 0..1

c.       maintains access to the other SWE QuantityRange attributes like uom, description, etc

2.       Put the new GSML_QuantityRange class in the CGI_Utilities package.

a.       this appears to be the logical place to put a GSML_QuantityRange class.  The EarthMaterial and GeologicUnit packages would need to be amended so that they import CGI_Utilities.

b.      alternatively, put GSML_QuantityRange in GeoSciML-Core. Then there is only one change to package imports --> CGI_Utilities must import GeosciML-Core.

c.       to avoid changing package imports at all, we would have to create a GSML_QuantityRange class in the CGI_Utilities, EarthMaterial, and GeologicUnit packages.

The nice thing about creating a child class of swe:QuantityRange is that we don’t have to change any of the attributes in the model which use the swe:QuantityRange property type.  Data providers will be presented with the option to use either swe:QuantityRange or gsmlu:GSML_QuantityRange. This is not ideal, but existing v3.1 services that use swe:QuantityRange would still be valid in v3.2.

An example v3.1 XML instance (this would still validate in v3.2):

                                                                <swe:description>The azimuth of the strike of the fault, measured in degrees</swe:description>
                                                                <swe:uom code="degree" xlink:href="http://www.opengis.net/def/uom/OGC/1.0/degree" xlink:title="degree"/>
                                                                <swe:value>110 130</swe:value>

An amended example v3.2 XML instance:

                                                                <swe:description>The azimuth of the strike of the fault, measured in degrees</swe:description>
                                                                <swe:uom code="degree" xlink:href="http://www.opengis.net/def/uom/OGC/1.0/degree" xlink:title="degree"/>
                                                                <swe:value>110 130</swe:value>

Please let me know what you think.



Ollie Raymond
Senior Geologist  - Information Management  |  Continental Geology Section
Minerals and Natural Hazards Division  |  GEOSCIENCE AUSTRALIA<http://www.ga.gov.au/>

Oceania Councillor & Interoperability Working Group
IUGS Commission for the Management and Application of Geoscience Information<http://www.cgi-iugs.org/>

Chair, GeoSciML Standards Working Group
Open Geospatial Consortium<http://www.opengeospatial.org/projects/groups/geoscimlswg>

Phone:  +61 2 6249 9575    Fax:  +61 2 6249 9971
Email:  Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>    Web:  www.ga.gov.au<http://www.ga.gov.au/>
Cnr Jerrabomberra Avenue and Hindmarsh Drive   Symonston   ACT
GPO Box 378   Canberra   ACT   2601   Australia

Applying geoscience to Australia’s most important challenges

Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is intended only for the person or entity to which it is addressed. If you are not the intended recipient, then you have received this e-mail by mistake and any use, dissemination, forwarding, printing or copying of this e-mail and its file attachments is prohibited. The security of emails transmitted cannot be guaranteed; by forwarding or replying to this email, you acknowledge and accept these risks.

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.

More information about the GeoSciML mailing list