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

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Wed Jul 3 05:08:28 EDT 2013


ah - I reused an existing CR as a template.  Missed that line.  sorry

________________________________
De : GeoSciML [geosciml-bounces at lists.opengeospatial.org] de la part de Oliver.Raymond at ga.gov.au [Oliver.Raymond at ga.gov.au]
Date d'envoi : 2 juillet 2013 20:55
À : geosciml at lists.opengeospatial.org
Objet : Re: [GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

Thanks Eric,

I have made some minor edits, including correcting the name of the standard that we want to change  ;-)

Cheers,
Ollie

_________________________________________________________________

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

From: GeoSciML [mailto:geosciml-bounces at lists.opengeospatial.org] On Behalf Of Boisvert, Eric
Sent: Wednesday, 3 July 2013 2:17 AM
To: Public: A mailing list for GeoSciML
Subject: Re: [GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]

Draft CR attached for your perusal


De : GeoSciML [mailto:geosciml-bounces at lists.opengeospatial.org] De la part de Oliver.Raymond at ga.gov.au<mailto:Oliver.Raymond at ga.gov.au>
Envoyé : 30 juin 2013 20:34
À : geosciml at lists.opengeospatial.org<mailto:geosciml at lists.opengeospatial.org>
Objet : Re: [GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]


Hi Eric,



I would still proceed with the CR, and I am more than happy for you to frame it  :-)   The current situation is messy and the SWECommon SWG should clean it up.



Unfortunately in GSML v3.2 we are stuck with the situation of having “swe:value”, “upperValue” and “lowerValue” all as valid options if we want to do this change as a v3.x change.  To remove swe:QuantityRange from the model altogether and replace it with our own QuantityRange is a non-backwardly-compatible change.  So, yes, it must be Schematron rules for v3.2 “gsmlu:GSML_QunatityRange”.



My feeling is that we need a Schematron rule that states “both lowerValue and upperValue should be present”.  In v3.1, we had to provide both upper and lower values because swe:value will not validate without two numbers.  So I think we should stick with that same intent.



As far as the ongoing use of swe:value goes, is there any use for swe:value at all if we can’t query it?  If someone can give me a use case for requiring its presence in a serialisation, then we can add it to the Schematron rule, but at the moment I’m happy to have the optional use of swe:value at the discretion of the data provider.



Cheers,

Ollie


____________________________________________________

Ollie Raymond
Senior Geologist  - Information Management  |  GEOSCIENCE AUSTRALIA<http://www.ga.gov.au/>
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


-----Original Message-----
From: GeoSciML [mailto:geosciml-bounces at lists.opengeospatial.org] On Behalf Of Boisvert, Eric
Sent: Monday, 1 July 2013 12:36 AM
To: Public: A mailing list for GeoSciML
Subject: Re: [GeoSciML] QuantityRange and GeoSciML v3.2 [SEC=UNCLASSIFIED]



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>

<gsml:lowerValue>90</gsml:lowerValue>

...

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<mailto: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).



John



From: geosciml-bounces+jll=bgs.ac.uk at lists.opengeospatial.org<mailto: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<mailto:Oliver.Raymond at ga.gov.au>

Sent: 26 June 2013 03:48

To: geosciml at lists.opengeospatial.org<mailto: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):



<gsmlst:planeOrientation>

                <gsmlu:CGI_PlanarOrientation>

                                …

                                <gsmlu:azimuth>

                                                <swe:QuantityRange>

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

                                                </swe:QuantityRange>

                                </gsmlu:azimuth>

                                …

                </gsmlu:CGI_PlanarOrientation>



An amended example v3.2 XML instance:



<gsmlst:planeOrientation>

                <gsmlu:CGI_PlanarOrientation>

                                …

                                <gsmlu:azimuth>

                                                <gsmlu:GSML_QuantityRange>

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

                                                                <gsmlu:lowerValue>110</gsmlu:lowerValue>

                                                                <gsmlu:upperValue>130</gsmlu:upperValue>

                                                </gsmlu:GSML_QuantityRange>

                                </gsmlu:azimuth>

                                …

                </gsmlu:CGI_PlanarOrientation>



Please let me know what you think.



Cheers,

Ollie



_________________________________________________________________



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<mailto:Oliver.Raymond at ga.gov.au%3cmailto:Oliver.Raymond at ga.gov.au>>    Web:  www.ga.gov.au<http://www.ga.gov.au/<UrlBlockedError.aspx>>

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.

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.
-------------------------------------------------------------------------------------------------------------------------

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.
-------------------------------------------------------------------------------------------------------------------------


More information about the GeoSciML mailing list